Donating a20-cubietruck board

[benn]

Dear list,

I'm Benn Huang from cubietech. I am very exciting to see such an active
community - linux-sunxi, and I know that many guys in the community
spend many days and nights for the community grow. I think the effort is
impossible to measured in money.

What I can do is to contribute my effort and ask allwinner to support us
better, and I will do it continuously.
Besides, I want to donate some a20-cubietruck boards and Cubie T-Shirts
to the people who make big contribute to the community.

About the a20-cubietruck, I think the big different are, (comparing to
previous cubieboard)
1. support 2.5/3.5 sata drive
2. 1000 Mbps NIC
3. wifi/bt on board
4. Li-Bat support
5. RTC support
6. VGA/HDMI support

all these will make thing very interesting.

About the T-Shirt, please look at
http://cubieboard.org/2013/09/07/a-colombia-friend-share-a-new-wallpaper-of-cubies/
1. that is an example make by hand, so the final t-shirt will look better
2. The logo is designed by a friend from colombia according to cubie
wallpapers.


For those who want to apply, please
1. tell the list who you are, and what effort have you made for the
linux-sunxi community

More to say
1. I am going to donating about 30 boards like last time, but at first I
can only provide 10 pieces because of the PCBs,
next production will send out the other boards
(so please let the maintainers first)
2. The T-Shirt will be more than 50 pcs

[benn]

the apply window will be close a week later, so please in hurry :P

[Hans de Goede]

Hi Ben,

On 09/11/2013 05:44 AM, benn wrote:
> Dear list,
>
> I'm Benn Huang from cubietech. I am very exciting to see such an active community - linux-sunxi, and I know that many guys in the community
> spend many days and nights for the community grow. I think the effort is impossible to measured in money.
>
> What I can do is to contribute my effort and ask allwinner to support us better, and I will do it continuously.
> Besides, I want to donate some a20-cubietruck boards and Cubie T-Shirts to the people who make big contribute to the community.
>
> About the a20-cubietruck, I think the big different are, (comparing to previous cubieboard)
> 1. support 2.5/3.5 sata drive
> 2. 1000 Mbps NIC
> 3. wifi/bt on board
> 4. Li-Bat support
> 5. RTC support
> 6. VGA/HDMI support
>
> all these will make thing very interesting.
>
> About the T-Shirt, please look at
> http://cubieboard.org/2013/09/07/a-colombia-friend-share-a-new-wallpaper-of-cubies/
> 1. that is an example make by hand, so the final t-shirt will look better
> 2. The logo is designed by a friend from colombia according to cubie wallpapers.
>
>
> For those who want to apply, please
> 1. tell the list who you are, and what effort have you made for the linux-sunxi community

I would like to receive one, my name is Hans de Goede, and I've been doing quite a bit on
the linux-sunxi kernel lately, I also am the creator and maintainer of the Fedora 18 and 19
images for A10(s) / A13 / A20 devices, so most people on the list probably already know me :)

Regards,

Hans

[Arokux X]

Hi Benn,

I am excited to read such a warm e-mail. Please do you best to convince Allwinner to work with sunxi.org as close as possible, the code piles that find their way to us (without history and commit messages) are not enough for us to mainline quickly as well as to fix bugs in the legacy kernel sunxi-3.4.

I will be very happy if you donate one Cubietruck along with T-Shirt (size L) to me! Currently I only have A10 hardware.

My contributions are:

- Support in the #linux-sunxi irc chat.

- Improvements to our wiki, see http://linux-sunxi.org/Special:Contributions/Arokux

- Clean up of the USB EHCI/OHCI in the sunxi-3.4, you can see it with git log --author=arokux

- Mainlining of the USB EHCI/OHCI. You can see initial code here https://github.com/arokux/linux/commits/sunxi-usb-host In last days I've found the last bit needed so, now it works flawlessly. Currently I'm cleaning it and soon will post patches against mainline.

- Last but not least, I test new fixes and drivers. :)

Best,

Arokux

[benn]

get it, thanks.

Best,

Arokux

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ian Campbell]

Hi Benn,

On Wed, 2013-09-11 at 11:44 +0800, benn wrote:

> For those who want to apply, please
> 1. tell the list who you are, and what effort have you made for the
> linux-sunxi community

I'm one of the upstream maintainers for the Xen port to ARM processors.
I've only contributed a couple of small patches to the linux-sunxi
community however I've been working on getting the Xen hypervisor
running on the cubieboard2 (see [1], still WIP) and would like very much
to be able to support the cubietruck too.

I'd be happy if you could send me a cubietruck but I would completely
understand if the above doesn't meet the conditions.

T-shirt-wise I'm an XL.

Thanks,
Ian.

[1] http://lists.xen.org/archives/html/xen-devel/2013-09/msg00880.html

[Rosimildo DaSilva]

Where is the Spec for this board ?, specially the connectivity ( connectors and headers ).

R

[Arokux X]

On Wed, Sep 11, 2013 at 2:27 PM, Rosimildo DaSilva <rosi...@gmail.com> wrote:

Where is the Spec for this board ?, specially the connectivity ( connectors and headers ).

R

http://lmgtfy.com/?q=cubietruck

[benn]

On 2013年09月11日 20:27, Rosimildo DaSilva wrote:

Where is the Spec for this board ?, specially the connectivity ( connectors and headers ).

We are preparing for that. It will be available very soon.

[thomas schorpp]

Hi cubitech

Am 11.09.2013 05:44, schrieb benn:
> Dear list,
>
> I'm Benn Huang from cubietech. I am very exciting to see such an active community - linux-sunxi, and I know that many guys in the community
> spend many days and nights for the community grow. I think the effort is impossible to measured in money.
>
> What I can do is to contribute my effort and ask allwinner to support us better, and I will do it continuously.
> Besides, I want to donate some a20-cubietruck boards and Cubie T-Shirts to the people who make big contribute to the community.
>
> About the a20-cubietruck, I think the big different are, (comparing to previous cubieboard)
> 1. support 2.5/3.5 sata drive
> 2. 1000 Mbps NIC
> 3. wifi/bt on board
> 4. Li-Bat support
> 5. RTC support
> 6. VGA/HDMI support
>
> all these will make thing very interesting.
>
> About the T-Shirt, please look at
> http://cubieboard.org/2013/09/07/a-colombia-friend-share-a-new-wallpaper-of-cubies/
> 1. that is an example make by hand, so the final t-shirt will look better
> 2. The logo is designed by a friend from colombia according to cubie wallpapers.
>
>
> For those who want to apply, please
> 1. tell the list who you are, and what effort have you made for the linux-sunxi community

I'm on software and hardware to support DVB- receiver modules like the Philips CU1216 connected directly on the Ax0 Transport Stream Controller Interface,
to avoid the need for DVB- usb bridges for VDR, XBMC, Mythv, etc, and so to have our USB busses free for other uses.

If You and the other devs/users here want (ATSC?)DVB- tuner support and Your (TS0/1)CSI0/1 is NOT GPIO- connector pin compatible with the Olimex Ax0 micro,
https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A10-OLinuXino-MICRO
and You've got at least (CSI0)TS0 or 1 on GPIO connectors

You should add me, too, for any Ax0 cubieboard model sample with those TS on GPIO, low priority,

so we have a common hardware base for development, and the wiki states cubieboards are "featured" here,
for the SMT connector receiver module extension board I'll design and build as soon as my low retirement funds allow it, next weeks.

A basic Android alpha driver from Allwinnertech has been already ported by me to linux-sunxi and is (for basic init sequences) tested:
[PATCH v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)
from 8/14/2013 is last state on mailing list, don't know if maintainer's have commited it already.

Or the devs with cubieboard ask Olimex to donate one? ;-) CC'd johns9...@yahoo.co.uk .

We need at least one more Olimex Ax0 for a linux-dvb / DMA - developer, or 2 Ax0 cubies, I cannot promise I can achieve that alone, and I will take many months if alone,
anyway, we need the VE for MPEG2/4 decoding DVB- streams, will take months, too, until stable for A20?
Building the DVB- receiver extension board is easy, most dvb-developers can assemble it in less than 2 hours, if not I would provide a DVB-C board at
the PCB, linear and connector parts and postage costs, DVB-S is more complex because of the need for a LNB driver circuit (and software driver adaption).
Even DVB-S2 boards can be build from parts cheap around on Ebay, but this needs stable working high performance DMA and h.264 VE decoding for live TV display.

...

I hereby [RFC] all (extension) board manufacturers to agree to extension connector pin compatibility in future revisions, at least for the CSI(TS) ports
or what else the users and devs interested in, too, and or provide SMT connector adapters (maybe the cheaper way and for older revisions).

This would make business easier for all extension board suppliers, and all claim "Open Hardware", so there's no reason for proprietary GPIO designs.

Y
tom

[Bastiaan van den Berg]

On Wed, Sep 11, 2013 at 5:44 AM, benn <benn....@gmail.com> wrote:

Dear list,

For those who want to apply, please
1. tell the list who you are, and what effort have you made for the linux-sunxi community

Heya,

 I am buZz and one of the supporters in both the #cubieboard and #linux-sunxi IRC channels.

 Have been introducing a lot of people to the wonderfull world of allwinner's chips and designing cases for it over on thingiverse.com

 I would _love_ to get a cubieboard tshirt :D

--

buZz 

[Henrik Nordström]

ons 2013-09-11 klockan 11:44 +0800 skrev benn:

> Besides, I want to donate some a20-cubietruck boards and Cubie T-Shirts
> to the people who make big contribute to the community.

I maintain the community u-boot version with SPL support for sunxi, and
it is good if I have a board to verify releases on and to debug any
issues seen with specific board.

T-shirt size is large.

Regards
Henrik

[Henrik Nordström]

ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:

> I hereby [RFC] all (extension) board manufacturers to agree to extension connector pin compatibility in future revisions, at least for the CSI(TS) ports
> or what else the users and devs interested in, too, and or provide SMT connector adapters (maybe the cheaper way and for older revisions).
>

This neeed so go to the mailinglist to have any effect.

Cubieboard and OLinuXIno boards uses different extension headers
entirely, both in size, type and pinout.

> This would make business easier for all extension board suppliers, and all claim "Open Hardware", so there's no reason for proprietary GPIO designs.

Yes, but not always possible, there is different constraints in size.

Regards
Henrik

[thomas schorpp]

Am 12.09.2013 11:36, schrieb Henrik Nordstr�m:
> ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:
>
>> I hereby [RFC] all (extension) board manufacturers to agree to extension connector pin compatibility in future revisions, at least for the CSI(TS) ports
>> or what else the users and devs interested in, too, and or provide SMT connector adapters (maybe the cheaper way and for older revisions).
>>
>
> This neeed so go to the mailinglist to have any effect.

?

Message-ID: <5230B710...@gmail.com> To: linux...@googlegroups.com

>
> Cubieboard and OLinuXIno boards uses different extension headers
> entirely, both in size, type and pinout.

Olimex A20 uses "standard" 2.54 mm pitch, 40 pins, 2�20 (2 rows of 20 pins) IDC SMT male connectors (like PATA IDE),
https://en.wikipedia.org/wiki/Insulation-displacement_connector

Cubieboard male "simple" pin headers typically spaced 0.1 inches (2.54 mm) >2x20,
https://en.wikipedia.org/wiki/Pin_header

looks compatible, if not millimetres (0.079 in) or 0.05 inches (1.27 mm) pitch,
http://blogzs1jen.dyndns.org:83/wp-content/gallery/cubieboard-accessories/breadboard_640.jpg
http://ubuntuone.com/62cLCytl7yfB9ElgIFEeon , p.1,7.

Cubietech (owners) confirm?

>
>> This would make business easier for all extension board suppliers, and all claim "Open Hardware", so there's no reason for proprietary GPIO designs.
>
> Yes, but not always possible, there is different constraints in size.

Sure.

>
> Regards
> Henrik
>

y
tom

[Michal Suchanek]

On 12 September 2013 13:29, thomas schorpp <thomas....@gmail.com> wrote:

> Am 12.09.2013 11:36, schrieb Henrik Nordström:
>>
>> ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:

>>
>> Cubieboard and OLinuXIno boards uses different extension headers
>> entirely, both in size, type and pinout.
>
>
> Olimex A20 uses "standard" 2.54 mm pitch, 40 pins, 2×20 (2 rows of 20 pins)
> IDC SMT male connectors (like PATA IDE),
> https://en.wikipedia.org/wiki/Insulation-displacement_connector
>
> Cubieboard male "simple" pin headers typically spaced 0.1 inches (2.54 mm)
>>2x20,
> https://en.wikipedia.org/wiki/Pin_header
>
> looks compatible, if not millimetres (0.079 in) or 0.05 inches (1.27 mm)
> pitch,
> http://blogzs1jen.dyndns.org:83/wp-content/gallery/cubieboard-accessories/breadboard_640.jpg
> http://ubuntuone.com/62cLCytl7yfB9ElgIFEeon , p.1,7.

Cubieboard uses something like 22x2 2mm pitch headers. The pin count
is strange and the 2mm headers are way less common. I guess getting
these connectors in China is not that much of a problem but getting
them in most parts of Europe is somewhat challenging. Most stores
carry 2.54 mm connectors and you can still get the 40pin cables for
IDE disks which make olinuxino really easy to connect.

The easiest way to connect cubieboard is probably 2.5" to 3.5" IDE
disk adaptor cable. It does not connect all pins but for most
applications you don't need all of them anyway. If you base on the
40pin IDE you can connect cubieboard to olinuxino extensions with some
lead swapping on the 2mm side of the cable I guess.

Of course, 2mm headers make it possible to build small and cute boards.

Thanks

Michal

[thomas schorpp]

Am 12.09.2013 17:02, schrieb Michal Suchanek:
> On 12 September 2013 13:29, thomas schorpp <thomas....@gmail.com> wrote:

>> Am 12.09.2013 11:36, schrieb Henrik Nordstr�m:
>>>
>>> ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:
>
>>>
>>> Cubieboard and OLinuXIno boards uses different extension headers
>>> entirely, both in size, type and pinout.
>>
>>
>> Olimex A20 uses "standard" 2.54 mm pitch, 40 pins, 2�20 (2 rows of 20 pins)
>> IDC SMT male connectors (like PATA IDE),
>> https://en.wikipedia.org/wiki/Insulation-displacement_connector
>>
>> Cubieboard male "simple" pin headers typically spaced 0.1 inches (2.54 mm)
>>> 2x20,
>> https://en.wikipedia.org/wiki/Pin_header
>>
>> looks compatible, if not millimetres (0.079 in) or 0.05 inches (1.27 mm)
>> pitch,
>> http://blogzs1jen.dyndns.org:83/wp-content/gallery/cubieboard-accessories/breadboard_640.jpg
>> http://ubuntuone.com/62cLCytl7yfB9ElgIFEeon , p.1,7.
>
> Cubieboard uses something like 22x2 2mm pitch headers. The pin count
> is strange

It's not "strange", it looks like typical proprietary closed hardware design to me, like all those
MK8xx, etc, Android boards.

> and the 2mm headers are way less common. I guess getting
> these connectors in China is not that much of a problem but getting
> them in most parts of Europe is somewhat challenging.

Well, anyway, since Cubietech's main interest seems to be software only:
http://cubieboard.org/docs/
and I've got not time and nerves to dig thru their webforum to collect parts for puzzles, sorry,

I'm taking Olimex as "featured" for hardware projects, my sample request to Cubietech is taken back,
Thanks.

>
> Thanks
>
> Michal
>

y
tom

[Michal Suchanek]

How is that closed design? The pinout is available eg. here:
http://linux-sunxi.org/Cubieboard/ExpansionPorts

There is even a link from the cubieboard.org support section as well
as the docs section.

The strange bit is that most available connectors have different pin
count - something like 20x2 or 25x2 - not 22x2.

>
>
>> and the 2mm headers are way less common. I guess getting
>> these connectors in China is not that much of a problem but getting
>> them in most parts of Europe is somewhat challenging.
>
>
> Well, anyway, since Cubietech's main interest seems to be software only:
> http://cubieboard.org/docs/
> and I've got not time and nerves to dig thru their webforum to collect parts
> for puzzles, sorry,

Yes, the cubieboard documentation could improve still but at this
point it's quite easy to find and extensive. You definitely don't have
to fish in a web forum.

>
> I'm taking Olimex as "featured" for hardware projects, my sample request to
> Cubietech is taken back,
> Thanks.

Olimex certainly makes hardware hacking easier. After all they are in
Europe and tailor their boards to European customers that use parts
common in Europe.


Thanks

Michal

[thomas schorpp]

What? Is linux-sunxi.org now a manufacturer of cubieboards?

Or is linux-sunxi.org a department of Cubietech? The wiki looks like.*

Are You kidding me?

Never read the footer of datasheets?
"All specification is subject to change without notice.",
expect that with every new PCB rev. and state it in the wiki, thank You.

>
> There is even a link from the cubieboard.org support section as well
> as the docs section.

*Circular link:
http://cubieboard.org/support/ -> http://linux-sunxi.org/Cubieboard

NO schematics, no PCB layout, specs for SOFTWARE makers only:
http://cubiebook.org/index.php?title=Main_Page#Cubieboard2.28Main_Chip:A20.29

>
> The strange bit is that most available connectors have different pin
> count - something like 20x2 or 25x2 - not 22x2.
>
>>
>>
>>> and the 2mm headers are way less common. I guess getting
>>> these connectors in China is not that much of a problem but getting
>>> them in most parts of Europe is somewhat challenging.
>>
>>
>> Well, anyway, since Cubietech's main interest seems to be software only:
>> http://cubieboard.org/docs/
>> and I've got not time and nerves to dig thru their webforum to collect parts
>> for puzzles, sorry,
>
> Yes, the cubieboard documentation could improve still but at this
> point it's quite easy to find and extensive. You definitely don't have
> to fish in a web forum.

No link(s). Noone knows what EXACTLY You're talking of, sorry.

>
>>
>> I'm taking Olimex as "featured" for hardware projects, my sample request to
>> Cubietech is taken back,
>> Thanks.
>
> Olimex certainly makes hardware hacking easier. After all they are in
> Europe and tailor their boards to European customers that use parts
> common in Europe.

IDC IDE connectors have been designed in Europe? By who? Siemens?
Molex has been a U.S.- Enterprise since the 60s.

>
>
> Thanks
>
> Michal
>

y
tom

[thomas schorpp]

Insufficent for hardware makers, for high speed signalling applications e.g. You need the schematics
and PCB layout SoC <-> PIN header, because those PIN header GPIO ports are NOT standarded like PCI e.g.

>
>
> Thanks
>
> Michal
>

y
tom

[Patrick Wood]

I would be interesting in getting a cubietruck; however, I'll be away on vacation starting in a week and won't be back until 1 Oct, so I can wait for a board from the second batch.

I've spent most of my time recently working on the sun7i nand driver and nand partition tool, g2d, cedarx, and just general testing of the gpio and mali drivers on the CB2.  I've spent a bit of time already working with a couple of different USB bluetooth adapters on the CB1, which work fine right out of the box.  But it looks like someone's (me?) going to have to bring up the AP6210 driver on the 3.4 branch, as I could only find android linux drivers for it.

+1 for Hans and Henrik getting one from the first batch, by the way.

Pat

[Michal Suchanek]

Cubietech is one of the contributors to the wiki. For me it's enough
that one copy of the information exists and there is link form the
cubieboard page. Sure they could make a copy in a PDF manual or
something but it's mostly wasted effort.

>
> Are You kidding me?
>
> Never read the footer of datasheets?
> "All specification is subject to change without notice.",
> expect that with every new PCB rev. and state it in the wiki, thank You.

That's common disclaimer. Maybe odd for a devboard but hey, you can
ask what version you are getting or even get custom modification when
ordering in bulk.

>
>
>>
>> There is even a link from the cubieboard.org support section as well
>> as the docs section.
>
>
> *Circular link:
> http://cubieboard.org/support/ -> http://linux-sunxi.org/Cubieboard

Your browser has tracking of visited links so you can see to what
sites you already were to if your memory can't hold that information.
I prefer circular links so that you can get from every site to every
other related site to one-way links which keep you wondering how the
hell you got there.

>
> NO schematics, no PCB layout, specs for SOFTWARE makers only:
> http://cubiebook.org/index.php?title=Main_Page#Cubieboard2.28Main_Chip:A20.29

Schematics are in the download section (and surely linked from
elsewhere) but they are unfortunately not up-to-date. That's one gripe
that could be easily resolved by cubietech but not addressed so far.
The label says the schematic is same for 0909 version but there were a
few differences from actual hardware identified.

>
>
>>
>> The strange bit is that most available connectors have different pin
>> count - something like 20x2 or 25x2 - not 22x2.
>>
>>>
>>>
>>>> and the 2mm headers are way less common. I guess getting
>>>> these connectors in China is not that much of a problem but getting
>>>> them in most parts of Europe is somewhat challenging.
>>>
>>>
>>>
>>> Well, anyway, since Cubietech's main interest seems to be software only:
>>> http://cubieboard.org/docs/
>>> and I've got not time and nerves to dig thru their webforum to collect
>>> parts
>>> for puzzles, sorry,
>>
>>
>> Yes, the cubieboard documentation could improve still but at this
>> point it's quite easy to find and extensive. You definitely don't have
>> to fish in a web forum.
>
>
> No link(s). Noone knows what EXACTLY You're talking of, sorry.

The links to cubiebook.org and linux-sunxi.org are in plain sight
duplicated in both support and resources sections of cubieboard.org.

It's not been always the case but whoever is taking care of the site
is doing decent job and it's quite usable now.

>
>
>>
>>>
>>> I'm taking Olimex as "featured" for hardware projects, my sample request
>>> to
>>> Cubietech is taken back,
>>> Thanks.
>>
>>
>> Olimex certainly makes hardware hacking easier. After all they are in
>> Europe and tailor their boards to European customers that use parts
>> common in Europe.
>
>
> IDC IDE connectors have been designed in Europe? By who? Siemens?
> Molex has been a U.S.- Enterprise since the 60s.

Being common in an area and being deigned in an area are two different
things. Of course the 2.54 mm connectors are US size. That does not
mean you cannot get an US connector in every other computer store and
every electronic parts store, unlike the 2mm ones.

Thanks

Michal

[Patrick Wood]

2.0mm headers are common in Japan and China. Cubietech is a Chinese company. Get over it.

[Huang Benn]

thanks for your advice and sorry for my late response. Actually, TS module is a bit beyond my knowledge, so I did not know what to say sometimes. But I do remember few months ago, somebody in the community ask for the TS datasheet, And I asked for it from allwinner.

So there is a public TS datasheet with watermark 'for cubieboard only' made by allwinner.

http://cubiebook.org/index.php?title=Main_Page#Docs

http://ubuntuone.com/5tBbYKV0jD2PD7FD6NBEdq

>
> We need at least one more Olimex Ax0 for a linux-dvb / DMA - developer, or 2 Ax0 cubies, I cannot promise I can achieve that alone, and I will take many months if alone,
> anyway, we need the VE for MPEG2/4 decoding DVB- streams, will take months, too, until stable for A20?
> Building the DVB- receiver extension board is easy, most dvb-developers can assemble it in less than 2 hours, if not I would provide a DVB-C board at
> the PCB, linear and connector parts and postage costs, DVB-S is more complex because of the need for a LNB driver circuit (and software driver adaption).
> Even DVB-S2 boards can be build from parts cheap around on Ebay, but this needs stable working high performance DMA and h.264 VE decoding for live TV display.
>
> ...
>
> I hereby [RFC] all (extension) board manufacturers to agree to extension connector pin compatibility in future revisions, at least for the CSI(TS) ports

It's a good suggestion. I think we will consider it of course

> or what else the users and devs interested in, too, and or provide SMT connector adapters (maybe the cheaper way and for older revisions).
>
> This would make business easier for all extension board suppliers, and all claim "Open Hardware", so there's no reason for proprietary GPIO designs.
>
> Y
> tom
>
>

[Huang Benn]

2013/9/13 thomas schorpp <thomas....@gmail.com>

Am 12.09.2013 17:02, schrieb Michal Suchanek:

On 12 September 2013 13:29, thomas schorpp <thomas....@gmail.com> wrote:

Am 12.09.2013 11:36, schrieb Henrik Nordström:

ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:

Cubieboard and OLinuXIno boards uses different extension headers
entirely, both in size, type and pinout.

Olimex A20 uses "standard" 2.54 mm pitch, 40 pins, 2×20 (2 rows of 20 pins)
IDC SMT male connectors (like PATA IDE),
https://en.wikipedia.org/wiki/Insulation-displacement_connector

Cubieboard male "simple" pin headers typically spaced 0.1 inches (2.54 mm)

2x20,

https://en.wikipedia.org/wiki/Pin_header

looks compatible, if not  millimetres (0.079 in) or 0.05 inches (1.27 mm)
pitch,
http://blogzs1jen.dyndns.org:83/wp-content/gallery/cubieboard-accessories/breadboard_640.jpg
http://ubuntuone.com/62cLCytl7yfB9ElgIFEeon , p.1,7.

Cubieboard uses something like 22x2 2mm pitch headers. The pin count
is strange

It's not "strange", it looks like typical proprietary closed hardware design to me, like all those
MK8xx, etc, Android boards.

Sincerely speaking，cb0808 is almost exactly the same with cb0909, but with minor fix to the sata. Yes, we can say, cbteam save a little bit change or fix,  which is totally without any technical difficulties. But in china, this is so important to protect ourselves. If you provide PCB layout, you will see many cubie-like boards on the market, then cubie dies, someone survival.

I think cubie is still a friendly member of linux-sunxi, we are trying hard to contribute our effort. You can see many manual written by cubieteam in linux-sunxi with bad English. we are not English-speaking guys but still try hard to write many Chinese English to make us understand.

 

and the 2mm headers are way less common. I guengss getti

these connectors in China is not that much of a problem but getting
them in most parts of Europe is somewhat challenging.

Well, anyway, since Cubietech's main interest seems to be software only:
http://cubieboard.org/docs/
and I've got not time and nerves to dig thru their webforum to collect parts for puzzles, sorry,

I'm taking Olimex as "featured" for hardware projects, my sample request to Cubietech is taken back,
Thanks.

Thanks

Michal

y
tom

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.

[Wolfgang Wegner]

On Sat, Sep 14, 2013 at 12:13:45AM +0800, Huang Benn wrote:
>
> thanks for your advice and sorry for my late response. Actually, TS module
> is a bit beyond my knowledge, so I did not know what to say sometimes. But
> I do remember few months ago, somebody in the community ask for the TS
> datasheet, And I asked for it from allwinner.
>
> So there is a public TS datasheet with watermark 'for cubieboard only' made
> by allwinner.
>
> http://cubiebook.org/index.php?title=Main_Page#Docs
>
> http://ubuntuone.com/5tBbYKV0jD2PD7FD6NBEdq

That's great news!
Thank you and Thomas for the effort! I would so love to see Ax0 as the
first real all-in-one device for VDR and such stuff...

Best regards,
Wolfgang

[Alejandro Mery]

http://dl.cubieboard.org/hardware/cubieboard_schematic_2012-08-08.pdf

and the wiki page binds each pin of the extension headers to the
corresponding SoC pin and it's possible MUX values.

http://dl.cubieboard.org/hardware/ has all you need to make your
daughter board that is not generic to all A10 or A20.

regards,
Alejandro Mery

[thomas schorpp]

Thanks.

Can anyone see or tell possible high speed (serial) DVB-TS signal limiting or interfering EMC (printed) components or layout
(for CE conformance) in those files?
Any PSpice data?

>
> http://dl.cubieboard.org/hardware/ has all you need to make your daughter board that is not generic to all A10 or A20.

Has it? Has it got Windows licences, 2GB extra RAM and 3GB extra HDD space -for a viewer- for us, too?
http://images.autodesk.com/adsk/files/dwg_trueview_system_requirements-FY14.pdf

http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=9078813#

253M 14. Sep 02:06 SetupDWGTrueView2014_ENU_32bit.sfx.exe

$ wine SetupDWGTrueView2014_ENU_32bit.sfx.exe
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
wine: Call from 0x7b8458e0 to unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName, aborting
wine: Unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName called at address 0x7b8458e0 (thread 0009), starting debugger...
Unhandled exception: unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName called in 32-bit code (0x7b845932).

335M 14. Sep 02:10 SetupDWGTrueView2014_ENU_64bit.sfx.exe

$ wine SetupDWGTrueView2014_ENU_64bit.sfx.exe
-------------------------------------------------------------^^
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
wine: Call from 0x7b8458e0 to unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName, aborting
wine: Unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName called at address 0x7b8458e0 (thread 0009), starting debugger...
Unhandled exception: unimplemented function gdiplus.dll.GdipCreateFontFamilyFromName called in 32-bit code (0x7b845932).
----------------------------------------------------------------------------------------------------------------------------------------------------------------^^

$ rm *DWG*

Anyone got this monster setup and run on recent wine versions or do we've got an OSS viewer anywhere?

Is Autocad and Windows "common" for schematics and PCB design in China and Japan, too?

>
> regards,
> Alejandro Mery
>

y
tom

[thomas schorpp]

Am 14.09.2013 00:07, schrieb Alejandro Mery:

Thanks, but cannot open Autocad files,
CSI extension hardware developers/users, can You tell the maximum signalling/data ratings within CE EMC requirements?

[thomas schorpp]

Look for Mele e.g, if You want something for production use, I'm here for DIY- lab fun :D

>
> Best regards,
> Wolfgang
>

y
tom

[Henrik Nordström]

fre 2013-09-13 klockan 00:55 +0200 skrev thomas schorpp:

> Insufficent for hardware makers, for high speed signalling applications e.g. You need the schematics
> and PCB layout SoC <-> PIN header, because those PIN header GPIO ports are NOT standarded like PCI e.g.

The GPIO is not exactly high speed signalling.

Regards
Henrik

[Bamvor Jian Zhang]

Hi, Benn


i am a allwinner soc fans, i buy lots of allwinner devices for using and hacking. Such as mele A1000, onta pad, cubieboard, mele M9.


recently, i am trying to port xen to A31[1]. meanwhile, i improve documents for mele M9[2][3].


if i could get a cubietruck, i could try xen and opensuse on it. i know i am not a developer in linux-sunxi, I would completely understand if the above doesn't meet the conditions.


T-shirt size is XL.


regards


bamvor


[1] http://lists.xen.org/archives/html/xen-devel/2013-07/msg01233.html
[2] http://linux-sunxi.org/Mele_M9
[3] http://linux-sunxi.org/PhoenixCard#PhoenixCard_for_A31

[Siarhei Siamashka]

On Wed, 11 Sep 2013 10:54:41 +0200
Arokux X <aro...@gmail.com> wrote:

> Hi Benn,
>
> I am excited to read such a warm e-mail. Please do you best to convince
> Allwinner to work with sunxi.org as close as possible, the code piles that
> find their way to us (without history and commit messages) are not enough
> for us to mainline quickly as well as to fix bugs in the legacy kernel
> sunxi-3.4.
>
> I will be very happy if you donate one Cubietruck along with T-Shirt (size
> L) to me! Currently I only have A10 hardware.
>
> My contributions are:
>
> - Support in the #linux-sunxi irc chat.
> - Improvements to our wiki, see
> http://linux-sunxi.org/Special:Contributions/Arokux
> - Clean up of the USB EHCI/OHCI in the sunxi-3.4, you can see it with git
> log --author=arokux
> - Mainlining of the USB EHCI/OHCI. You can see initial code here
> https://github.com/arokux/linux/commits/sunxi-usb-host In last days I've
> found the last bit needed so, now it works flawlessly. Currently I'm
> cleaning it and soon will post patches against mainline.
> - Last but not least, I test new fixes and drivers. :)

Hi Arokux X,

I'm just curious and you don't have to reply if you don't want to. But
weren't you afraid that somebody could track you down and identify your
real name or something?

http://irclog.whitequark.org/linux-sunxi/2013-08-05#4605275;

Now I wonder what kind of delivery address you are going to use for
receiving a donated board in order to protect your secret identity?

--
Best regards,
Siarhei Siamashka

[thomas schorpp]

Am 13.09.2013 18:13, schrieb Huang Benn:
> 在 2013-9-12 AM2:31，"thomas schorpp" <thomas....@gmail.com>写道：
>>
>> Hi cubitech

>> A basic Android alpha driver from Allwinnertech has been already ported
>> by me to linux-sunxi and is (for basic init sequences) tested:
>> [PATCH v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC)
>> Transport Stream Controller(s) (TSC)
>> from 8/14/2013 is last state on mailing list, don't know if maintainer's
>> have commited it already.
>>
>> Or the devs with cubieboard ask Olimex to donate one? ;-) CC'd
> johns9...@yahoo.co.uk .
>
> thanks for your advice and sorry for my late response. Actually, TS module
> is a bit beyond my knowledge, so I did not know what to say sometimes. But
> I do remember few months ago, somebody in the community ask for the TS
> datasheet, And I asked for it from allwinner.
>
> So there is a public TS datasheet with watermark 'for cubieboard only' made
> by allwinner.
>
> http://cubiebook.org/index.php?title=Main_Page#Docs
>
> http://ubuntuone.com/5tBbYKV0jD2PD7FD6NBEdq

Thank You very much, and sorry for the late response to this.

Since many TS recorders like VDR need the full transponder transport stream passed to,
we should not need the higher (PID filter, etc) functions of the TSC, disabled by default in TSF ~ +0x30,
only "DVB Bus"- receiver module interface handling and passthru to /dev/dvb/.../dvr with DMA and
setting the correct TS stream parameters according to the tuned transponder respectively.

Is "somebody" working on OSS IPTV- support for the TSC?

y
tom

[thomas schorpp]

Who told You that?

See GPIO mux table in A20 manual, Olimex schematic or TSC manual,
the PGx,PEx ports in TS mux mode for the TSC require SSI/SPI performance,
en.wikipedia,org is wrong, only the protocol and maybe cabling is standarded,
and see https://en.wikipedia.org/wiki/Digital_Video_Broadcasting#Transmission

Suggest You get a copy of the PCI 2.3 standard,

see the strict recommends of PCB layouts and connectors,

any hardware developer not taking this serious may run into severe trouble, even at 33MHz clocking.
Johnson's "High Speed Digital Design: A Handbook Of Black Magic", e.g. is not new but has got the very title.

Or buy one of this cheap PCI 90�/flat cable extenders on Ebay and see Your card fail ;-)

>
> Regards
> Henrik
>

y
tom

[Wolfgang Wegner]

On Sun, Sep 15, 2013 at 03:02:39AM +0200, thomas schorpp wrote:
>
> Thank You very much, and sorry for the late response to this.
>
> Since many TS recorders like VDR need the full transponder transport stream
> passed to,
> we should not need the higher (PID filter, etc) functions of the TSC,
> disabled by default in TSF ~ +0x30,
> only "DVB Bus"- receiver module interface handling and passthru to
> /dev/dvb/.../dvr with DMA and
> setting the correct TS stream parameters according to the tuned transponder
> respectively.

It has been quite some time since looking deeper into this, but AFAIK the
only reason for handling the full transport stream is that the old budget
cards were not able to do PID filtering in hardware. For regular use cases
like recording/streaming/watching some program(s), having the hardware
drop unneeded/unwanted packets leaves some room for processing more
actual payload data.

Furthermore, to do it right, special handling might also be needed or
at least useful in the case of live decoding (e.g. PCR/PTS decoding and
handling, DMA directly to the video/audio decoding buffers). There is
a reason why the "full-featured DVB cards" - doing the above internally -
still have some reputation for superior decoding quality.

Sorry for bringing this up without knowing how current VDR handles this,
but for really taking advantage of such multimedia SoCs, some minor
changes in VDR or the plugins might be needed...

Best regards,
Wolfgang

[Alejandro Mery]

try their browser version https://www.autocad360.com and then you can
probably export the views to dxf or something else more broadly
supported by free tools.

regards,
Alejandro Mery

[thomas schorpp]

Am 15.09.2013 10:09, schrieb Wolfgang Wegner:
> On Sun, Sep 15, 2013 at 03:02:39AM +0200, thomas schorpp wrote:
>>
>> Thank You very much, and sorry for the late response to this.
>>
>> Since many TS recorders like VDR need the full transponder transport stream
>> passed to,
>> we should not need the higher (PID filter, etc) functions of the TSC,
>> disabled by default in TSF ~ +0x30,
>> only "DVB Bus"- receiver module interface handling and passthru to
>> /dev/dvb/.../dvr with DMA and
>> setting the correct TS stream parameters according to the tuned transponder
>> respectively.
>
> It has been quite some time since looking deeper into this, but AFAIK the
> only reason for handling the full transport stream is that the old budget
> cards were not able to do PID filtering in hardware. For regular use cases

All the drivers of my dvb-t sticks and even a latest dvb-usb2 based driver
cannot do PID filtering (cheap demod chips hardware/firmware limitation or no manuals) and it is
not recommended, since it's a force option in the core:

root@vdr1:~# modinfo dvb-usb |grep -i pid
parm: force_pid_filter_usage:force all dvb-usb-devices to use a PID filter, if any (default: 0). (int)

> like recording/streaming/watching some program(s), having the hardware
> drop unneeded/unwanted packets leaves some room for processing more
> actual payload data.
>
> Furthermore, to do it right, special handling might also be needed or
> at least useful in the case of live decoding (e.g. PCR/PTS decoding and
> handling, DMA directly to the video/audio decoding buffers). There is
> a reason why the "full-featured DVB cards" - doing the above internally -
> still have some reputation for superior decoding quality.

Not anymore at nowadays high stream bitrates, VDR and driver (OSD UI) breakdown and corrupted recordings
on ARD/ZDF transponders in transfer mode due to hardware and driver limits (too high ioctl mutex lock contention).
You can only use legacy FF cards for MPEG2 decoding with disabled tuner, that's it.
Furthermore, if you enable PID filering in dvb-ttpci the driver and firmware will crash using vdr2.

>
> Sorry for bringing this up without knowing how current VDR handles this,
> but for really taking advantage of such multimedia SoCs, some minor
> changes in VDR or the plugins might be needed...
>
> Best regards,
> Wolfgang
>

y
tom

[Henrik Nordström]

sön 2013-09-15 klockan 03:59 +0200 skrev thomas schorpp:

> > The GPIO is not exactly high speed signalling.
>
> Who told You that?

Sorry, a terminology mixup. I misread you slightly thought you were
talking about GPIO and not a more advanced I/O block. GPIO is very slow
on Allwinner CPUs, but dedicated I/O blocks such as TS, MMC, SPI etc is
not.

Regards
Henrik

[thomas schorpp]

Thanks, but cannot do that, requires acknowlegde of terms only a native english speaking lawyer can read:
http://app.autocad360.com/createaccount/ ->
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=21614956

[thomas schorpp]

Who from http://www.henriknordstrom.se/ (?) told You that?

They're all "GPIO" with multiplexed functionality, see
https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A10-OLinuXino-MICRO/A10-A20-OLINUXINO-MICRO-4GB_Rev_D.pdf
A20 PIN A2 is muxed with UDMA5 performance PATA and low speed PS2 ;-)

And theres no economical reason for chip designers to
design "breaks" in because in modern chip maufacturing
process you can get the fastest I/O drivers at no extra cost
if you've got already one in.

y
tom

[Henrik Nordström]

sön 2013-09-15 klockan 22:40 +0200 skrev thomas schorpp:

> Who from http://www.henriknordstrom.se/ (?) told You that?

?

> They're all "GPIO" with multiplexed functionality, see
> https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A10-OLinuXino-MICRO/A10-A20-OLINUXINO-MICRO-4GB_Rev_D.pdf
> A20 PIN A2 is muxed with UDMA5 performance PATA and low speed PS2 ;-)

GPIO is just one of many muxed pin functions (or more precisely a
function provided by the pin-mux controller). The GPIO controller is
internally on a very slow bus.

Regards
Henrik

[John S]

They are indeed very very slow.  I was horrified at how slow.

I didn't find any documentation about it in case you know any?

Regards,

John

---

From: Henrik Nordström <hen...@henriknordstrom.net>
To: linux...@googlegroups.com
Sent: Sunday, 15 September 2013, 22:09
Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

[thomas schorpp]

Am 15.09.2013 23:24, schrieb John S:
> They are indeed very very slow. I was horrified at how slow.

Maybe misprogramming by software engineers *duck 'n' run* :D

>
> I didn't find any documentation about it in case you know any?

Would like to have, too.

>
>
> Regards,
>
> John
>

y
tom

P.S.:
Please don't top post on list threads and configure Your MUA to "shift" the citation with ">",
Thank You very much.

>
>
> ________________________________
> From: Henrik Nordstr�m <hen...@henriknordstrom.net>

[John S]

I don't believe misprogramming.  Same code works 7x faster on rPi than 1GHz A13 (tight loop waggling GPIO pin).  An 80MHz PIC32 is faster than A13.

If you need fast GPIO, be sure to test some simple code before worrying whether open hardware is as open as you'd like as you may find the CPU is far too slow for it to matter.  (BTW you could always make a one-off payment to have open hardware data format comverted to your preferred format.)

Regards,

John

---

From: thomas schorpp <thomas....@gmail.com>
To: linux...@googlegroups.com
Cc: John S <johns9...@yahoo.co.uk>; Henrik Nordström <hen...@henriknordstrom.net>
Sent: Monday, 16 September 2013, 14:50

Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

Am 15.09.2013 23:24, schrieb John S:
> They are indeed very very slow.  I was horrified at how slow.

Maybe misprogramming by software engineers *duck 'n' run* :D

>
> I didn't find any documentation about it in case you know any?

Would like to have, too.

>
>
> Regards,
>
> John
>

y
tom

P.S.:
Please don't top post on list threads and configure Your MUA to "shift" the citation with ">",
Thank You very much.

>
>
> ________________________________

>  From: Henrik Nordström <hen...@henriknordstrom.net>

> To: linux...@googlegroups.com
> Sent: Sunday, 15 September 2013, 22:09
> Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility
>
>
> GPIO is just one of many muxed pin functions (or more precisely a
> function provided by the pin-mux controller). The GPIO controller is
> internally on a very slow bus.
>
> Regards
> Henrik
>

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsub...@googlegroups.com.

[Henrik Nordström]

mån 2013-09-16 klockan 15:50 +0200 skrev thomas schorpp:
> Am 15.09.2013 23:24, schrieb John S:
> > They are indeed very very slow. I was horrified at how slow.
>
> Maybe misprogramming by software engineers *duck 'n' run* :D

There seems to be a 50% misprogramming somewhere in our kernel clock
setup last tiem I tried. But the the PIO block is far far away from the
CPU core on a low speed bus within the SoC which very much limits the
possible GPIO programming rate.

CPU -> AXI -> AHB -> APB0 -> Something even slower it seems

Regards
Henrik

[thomas schorpp]

Am 16.09.2013 16:08, schrieb John S:
> I don't believe misprogramming. Same code works 7x faster on rPi
> than 1GHz A13 (tight loop waggling GPIO pin). An 80MHz PIC32 is
> faster than A13.
>
> If you need fast GPIO, be sure to test some simple code before
> worrying whether open hardware is as open as you'd like as you may
> find the CPU is far too slow for it to matter.

Therefore DMA has been invented.
I believe to remember the manual it's supported for GPIO, by Your test code, too?
Polling without interrupt signalling slows down any CPU.

y
tom

> (BTW you could always
> make a one-off payment to have open hardware data format comverted to
> your preferred format.)
>
> Regards,
>
> John
>
>
> ________________________________ From: thomas schorpp
> <thomas....@gmail.com> To: linux...@googlegroups.com Cc: John

> S <johns9...@yahoo.co.uk>; Henrik Nordstr�m

> <hen...@henriknordstrom.net> Sent: Monday, 16 September 2013, 14:50
> Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on
> some GPIO connectors PIN- compatibility
>
>
> Am 15.09.2013 23:24, schrieb John S:
>> They are indeed very very slow. I was horrified at how slow.
>
> Maybe misprogramming by software engineers *duck 'n' run* :D
>
>>
>> I didn't find any documentation about it in case you know any?
>
> Would like to have, too.
>
>>
>>
>> Regards,
>>
>> John
>>
>
> y tom
>
> P.S.: Please don't top post on list threads and configure Your MUA to
> "shift" the citation with ">", Thank You very much.
>
>>
>>

>> ________________________________ From: Henrik Nordstr�m

[thomas schorpp]

Am 16.09.2013 16:08, schrieb John S:

> I don't believe misprogramming. Same code works 7x faster on rPi
> than 1GHz A13 (tight loop waggling GPIO pin). An 80MHz PIC32 is
> faster than A13.
>
> If you need fast GPIO, be sure to test some simple code before
> worrying whether open hardware is as open as you'd like as you may
> find the CPU is far too slow for it to matter.

I've been thinking of attaching up to 4 receiver modules to TS0,
every 1 with its serial output par Tsx Data Pin
with the TSC in SPI bypass to DMA mode if available
and then demux "the noise" in software to 4 /dev/dvb/a*0...a*3/dvr :D

y
tom

[Henrik Nordström]

mån 2013-09-16 klockan 22:03 +0200 skrev thomas schorpp:

> Therefore DMA has been invented.

There is no DMA to the GPIO contoller as far as I know. Not sure how
that would work.. what would clock the DMA?

Regards
Henrik

[John S]

Is DMA available for GPIO and will it be a lot faster on AW chips?

Let me know when/if you try it.  What doc I've seen might be flattered as "poor".

I didn't really wish to mess around with DMA and ring buffers just to avoid slow GPIO.  I'll find something else to do with AW boards and use rPi instead for GPIO.  Some other board, if needed - they're all getting affordable so may as well move on from any that are awkward to use for my GPIO needs.

Regards,

John

---

From: thomas schorpp <thomas....@gmail.com>
To: linux...@googlegroups.com
Cc: John S <johns9...@yahoo.co.uk>

Sent: Monday, 16 September 2013, 21:03

Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

Am 16.09.2013 16:08, schrieb John S:
> I don't believe misprogramming.  Same code works 7x faster on rPi
> than 1GHz A13 (tight loop waggling GPIO pin).  An 80MHz PIC32 is
> faster than A13.
>
> If you need fast GPIO, be sure to test some simple code before
> worrying whether open hardware is as open as you'd like as you may
> find the CPU is far too slow for it to matter.

Therefore DMA has been invented.
I believe to remember the manual it's supported for GPIO, by Your test code, too?
Polling without interrupt signalling slows down any CPU.

y
tom

> (BTW you could always
> make a one-off payment to have open hardware data format comverted to
> your preferred format.)
>
> Regards,
>
> John
>
>
> ________________________________ From: thomas schorpp
> <thomas....@gmail.com> To: linux...@googlegroups.com Cc: John

> S <johns9...@yahoo.co.uk>; Henrik Nordström

> <hen...@henriknordstrom.net> Sent: Monday, 16 September 2013, 14:50
> Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on
> some GPIO connectors PIN- compatibility
>
>
> Am 15.09.2013 23:24, schrieb John S:
>> They are indeed very very slow.  I was horrified at how slow.
>
> Maybe misprogramming by software engineers *duck 'n' run* :D
>
>>
>> I didn't find any documentation about it in case you know any?
>
> Would like to have, too.
>
>>
>>
>> Regards,
>>
>> John
>>
>
> y tom
>
> P.S.: Please don't top post on list threads and configure Your MUA to
> "shift" the citation with ">", Thank You very much.
>
>>
>>

>> ________________________________ From: Henrik Nordström

>> <hen...@henriknordstrom.net> To: linux...@googlegroups.com Sent:
>> Sunday, 15 September 2013, 22:09 Subject: Re: [linux-sunxi] [RFC]
>> Board manufacturers please agree on some GPIO connectors PIN-
>> compatibility
>>
>>
>> GPIO is just one of many muxed pin functions (or more precisely a
>> function provided by the pin-mux controller). The GPIO controller
>> is internally on a very slow bus.
>>
>> Regards Henrik
>>
>

[John S]

Quite - thanks,

John

---

From: Henrik Nordström <hen...@henriknordstrom.net>
To: linux...@googlegroups.com

Cc: John S <johns9...@yahoo.co.uk>
Sent: Monday, 16 September 2013, 20:34

Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

[thomas schorpp]

Am 16.09.2013 22:25, schrieb Henrik Nordstr�m:

Not sure, too, in input mode the IRQ on signal flank change?
Does the GPIO/IRC/DMAC support this?

Well, anyway, those all are no questions for my first TSC use case,
1 tuner, 6,9MSyms DVB-C, should work as designed for.

Thanks for the nice talk :-)

Get my lead iron hot tommorow for a quick connection on an old IDE 3,5" plug ;-)
No (P)CB daughterboard at first.
Then the I2C and frontend drivers modified, attached and running, hopefully.

y
tom

>
> Regards
> Henrik

[Henrik Nordström]

> There seems to be a 50% misprogramming somewhere in our kernel clock
> setup last tiem I tried.

Tested again and that error seem to have been corrected. I now get
7.5MHz toggle rate when trying to drive GPIO in both u-boot and linux.
Or maybe it's because I do not have cpufreq scaling enabled in this
kernel.. more testing needed.

this with a simple loop that only writes to the pin value register in
PIO.

Regards
Henrik

[Henrik Nordström]

mån 2013-09-16 klockan 22:44 +0200 skrev thomas schorpp:

> Not sure, too, in input mode the IRQ on signal flank change?
> Does the GPIO/IRC/DMAC support this?

I don't think so. I have only seen DMA mentioned when driven by some
smarter I/O block that knows when data needs to be clocked, for example
the TSC.

There is interrupt support in PIO, but enabling those pulls an interrupt
to the CPU which is not quite the same.

> Get my lead iron hot tommorow for a quick connection on an old IDE 3,5" plug ;-)
> No (P)CB daughterboard at first.
> Then the I2C and frontend drivers modified, attached and running, hopefully.

Interesting times ahead :)

Regards
Henrik

[John S]

Good - but have I understood this correctly i.e. that both u-boot and the kernel were (up to some change) running the CPU at half the speed that they now do?

Sorry to pester but where do I grab the current, faster, u-boot from?

I'll get it and look for the change.

John

---

From: Henrik Nordström <hen...@henriknordstrom.net>
To: linux...@googlegroups.com

Sent: Tuesday, 17 September 2013, 2:11

Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

[Oliver Schinagl]

On 13-09-13 18:37, Huang Benn wrote:
>
>
>
> 2013/9/13 thomas schorpp <thomas....@gmail.com
> <mailto:thomas....@gmail.com>>
>
> Am 12.09.2013 17:02, schrieb Michal Suchanek:
>
> On 12 September 2013 13:29, thomas schorpp
> <thomas....@gmail.com <mailto:thomas....@gmail.com>> wrote:
>
> Am 12.09.2013 11:36, schrieb Henrik Nordström:
>
>
> ons 2013-09-11 klockan 20:31 +0200 skrev thomas schorpp:
>
>
>
> Cubieboard and OLinuXIno boards uses different extension
> headers
> entirely, both in size, type and pinout.
>
>
>
> Olimex A20 uses "standard" 2.54 mm pitch, 40 pins, 2×20 (2
> rows of 20 pins)
> IDC SMT male connectors (like PATA IDE),
> https://en.wikipedia.org/wiki/__Insulation-displacement___connector
> <https://en.wikipedia.org/wiki/Insulation-displacement_connector>
>
> Cubieboard male "simple" pin headers typically spaced 0.1
> inches (2.54 mm)
>
> 2x20,
>
> https://en.wikipedia.org/wiki/__Pin_header
> <https://en.wikipedia.org/wiki/Pin_header>
>
> looks compatible, if not millimetres (0.079 in) or 0.05
> inches (1.27 mm)
> pitch,
> http://blogzs1jen.dyndns.org:__83/wp-content/gallery/__cubieboard-accessories/__breadboard_640.jpg
> <http://blogzs1jen.dyndns.org:83/wp-content/gallery/cubieboard-accessories/breadboard_640.jpg>
> http://ubuntuone.com/__62cLCytl7yfB9ElgIFEeon
> <http://ubuntuone.com/62cLCytl7yfB9ElgIFEeon> , p.1,7.
>
>
> Cubieboard uses something like 22x2 2mm pitch headers. The pin count
> is strange
>
>
> It's not "strange", it looks like typical proprietary closed
> hardware design to me, like all those
> MK8xx, etc, Android boards.
>
>
> Sincerely speaking，cb0808 is almost exactly the same with cb0909, but
> with minor fix to the sata. Yes, we can say, cbteam save a little bit
> change or fix, which is totally without any technical difficulties. But
> in china, this is so important to protect ourselves. If you provide PCB
> layout, you will see many cubie-like boards on the market, then cubie
> dies, someone survival.
Its quite understandable that you want to protect your designs,
openhardware works in europe as it's protected by copyright law. I
suppose in China the same would work, but those laws would be broken
left and right by immitators. So I understand your concern.

Maybe an idea is to release outdated schematics and/or on request? I
don't know what the best course of action would be here while still
being open and friendly.

>
> I think cubie is still a friendly member of linux-sunxi, we are trying
> hard to contribute our effort. You can see many manual written by
> cubieteam in linux-sunxi with bad English. we are not English-speaking
> guys but still try hard to write many Chinese English to make us
> understand.
I think your english is very understandable and you are trying well and
hard to support the community.

Thank you for that,

Oliver

>
>
>
> and the 2mm headers are way less common. I guengss getti
> these connectors in China is not that much of a problem but getting
> them in most parts of Europe is somewhat challenging.
>
>
> Well, anyway, since Cubietech's main interest seems to be software only:
> http://cubieboard.org/docs/
> and I've got not time and nerves to dig thru their webforum to
> collect parts for puzzles, sorry,
>
> I'm taking Olimex as "featured" for hardware projects, my sample
> request to Cubietech is taken back,
> Thanks.
>
>
> Thanks
>
> Michal
>
>
> y
> tom

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to linux-sunxi+unsubscribe@__googlegroups.com
> <mailto:linux-sunxi%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to linux-sunxi...@googlegroups.com.

[Henrik Nordström]

tis 2013-09-17 klockan 08:41 +0100 skrev John S:
> Good - but have I understood this correctly i.e. that both u-boot and
> the kernel were (up to some change) running the CPU at half the speed
> that they now do?

No, they both run the CPU at full speed, but there have long been an
issue that PIO accesses (GPIO, pin mux settings etc) have been 50%
slower in sunxi linux than u-boot or Allwinner Android linux.

Regards
Henrik

[John S]

I didn't know that!
Drat.

The most I recall is someone on A13 Olinuxino forum experimented with various clocks to look at DRAM speed.

No worries,

John

---

From: Henrik Nordström <hen...@henriknordstrom.net>
To: linux...@googlegroups.com

Sent: Tuesday, 17 September 2013, 15:56

Subject: Re: [linux-sunxi] [RFC] Board manufacturers please agree on some GPIO connectors PIN- compatibility

[thomas schorpp]

Am 17.09.2013 06:17, schrieb Oliver Schinagl:
>>On 13-09-13 18:37, Huang Benn wrote:
>>
>>
>>
>> 2013/9/13 thomas schorpp <thomas....@gmail.com
>> <mailto:thomas....@gmail.com>>

>> On 12 September 2013 13:29, thomas schorpp
>> <thomas....@gmail.com <mailto:thomas....@gmail.com>>
>> wrote:
>>

<snip , >> shift inlining fsck up bysome MUA>

>> It's not "strange", it looks like typical proprietary closed
>> hardware design to me, like all those MK8xx, etc, Android boards.
>>
>>

>> But in china, this is so important to protect
>> ourselves. If you provide PCB layout, you will see many cubie-like
>> boards on the market, then cubie dies, someone survival.

Like Olimex must do, too, then. Do You see them dying?

> Its quite understandable that you want to protect your designs,
> openhardware works in europe as it's protected by copyright law. I
> suppose in China the same would work, but those laws would be broken
> left and right by immitators. So I understand your concern.

His country has got market economy like we, same copyright laws like we
and signed the same international treaties to protect copyrights like we,

and Olimex would have far more costs to go from Bulgaria
to a Chinese court than Cubietech based in China, sorry Oliver, but
that's no point at all.

>
> Maybe an idea is to release outdated schematics and/or on request? I
> don't know what the best course of action would be here while still
> being open and friendly.

The "idea" is well known and named Non Disclosal Agreement (NDA).
Many OSS driver projects had to sign one,

using outdated schematics can be risky up to fire hazard dangerous in electronics,
because e.g. we've got switching power converters on the boards
and eventually external switching AC- adaptors for USB hubs,

and remember the massive EMC impact on my VDR host at my try to power my SATA HDD
from the Olimex A10/20 rev.B 5V connection place on my rev.C board, I reported in IRC,
what could get you the FCC FEDs (DE BnetzA) knocking on Your door with a 1000US$ fine :D

>
>>
>> I think cubie is still a friendly member of linux-sunxi, we are
>> trying hard to contribute our effort. You can see many manual
>> written by cubieteam in linux-sunxi with bad English. we are not
>> English-speaking guys but still try hard to write many Chinese
>> English to make us understand.

Your English hasn't been questioned.

> I think your english is very understandable and you are trying well
> and hard to support the community.

Fine for software. I've never questioned that, too.

Anyway, I'll accept this whole "linux-sunxi/Cubietech NDA" and will never question again,
but it should be written down and its existence published then, like all the other OSS projects do.

>
> Thank you for that,
>
> Oliver

y
tom

[Henrik Nordström]

tis 2013-09-17 klockan 18:39 +0200 skrev thomas schorpp:

> >> But in china, this is so important to protect
> >> ourselves. If you provide PCB layout, you will see many cubie-like
> >> boards on the market, then cubie dies, someone survival.
>
> Like Olimex must do, too, then. Do You see them dying?

Quite the opposite, they encourage users taking their designs and doing
their own boards based on them.

Benn, I am sorry but not publishing schematics and layout equals
closed/proprietary hardware, not open.

Publishing only schematics and supporting the community enters a grey
zone of "friendly", but still not open.

And in case of Cubieboard the published schematics is of very limited
value to Cubieboard owners as there is not even component placing
available so anyone looking at the hardware side have to trace out the
board themselves anyway...

> >> I think cubie is still a friendly member of linux-sunxi, we are
> >> trying hard to contribute our effort. You can see many manual
> >> written by cubieteam in linux-sunxi with bad English. we are not
> >> English-speaking guys but still try hard to write many Chinese
> >> English to make us understand.
>
> Your English hasn't been questioned.

Indeed. Most people on this globe (and in these mailinglists) are not
english native speaking, and language is not expected to be perfect by
anyone. Just sufficient to be understood.

> Anyway, I'll accept this whole "linux-sunxi/Cubietech NDA" and will never question again,
> but it should be written down and its existence published then, like all the other OSS projects do.

What NDA?

I must be missing something..

Regards
Henrik

[Jens Thiele]

thomas schorpp <thomas....@gmail.com> writes:

> and remember the massive EMC impact on my VDR host at my try to power
> my SATA HDD from the Olimex A10/20 rev.B 5V connection place on my
> rev.C board, I reported in IRC, what could get you the FCC FEDs (DE
> BnetzA) knocking on Your door with a 1000US$ fine :D

can you explain in more detail to a hardware noob, please? is only rev.B
effected? (having rev c and d here)
maybe off-list and in german if you prefer

greetings,
jens

[thomas schorpp]

Sorry, English is mandatory here and others may want to get my answer to this, too,
and there's no individual personal user support from OSS- projects to prefer:

Nothing is affected if You don't try my individual fun lab experiments at home.

>
> greetings,
> jens
>

y
tom

[thomas schorpp]

Am 17.09.2013 22:20, schrieb Henrik Nordstr�m:
> tis 2013-09-17 klockan 18:39 +0200 skrev thomas schorpp:
>
>>>> But in china, this is so important to protect
>>>> ourselves. If you provide PCB layout, you will see many cubie-like
>>>> boards on the market, then cubie dies, someone survival.
>>
>> Like Olimex must do, too, then. Do You see them dying?
>

>

> Publishing only schematics and supporting the community enters a grey
> zone of "friendly", but still not open.
>

Well, anyway, since he gets us manuals from Allwinnertech for making
Software for the boards, it's very friendly and fair enough for the
users and customers majority interested in best software.

The fewer hardware nerds can use Olimex e.g. OSHW boards, and we're all fine,
aren't we?

> What NDA?
>
> I must be missing something..

Forget it ^^

>
> Regards
> Henrik
>

y
tom

[thomas schorpp]

Am 15.09.2013 20:15, schrieb Alejandro Mery:
> On 14/09/13 02:50, thomas schorpp wrote:
>> Am 14.09.2013 00:07, schrieb Alejandro Mery:
>>> http://dl.cubieboard.org/hardware/ has all you need to make your
>>> daughter board that is not generic to all A10 or A20.
>>
>> Thanks, but cannot open Autocad files,
>
> try their browser version https://www.autocad360.com and then you can probably export the views to dxf or something else more broadly supported by free tools.
>

> regards,
> Alejandro Mery
>

FYI,

Found

LibreCAD
Version: 1.0.1
SCM Revision: 1.0.0

*** 1.0.1+nolibs-2~bpo60+1 0
100 http://backports.debian.org/debian-backports/ squeeze-backports/main amd64 Packages

is able to read
http://dl.cubieboard.org/hardware/cubieboard_outline_2012-08-08_v1.1.dxf
Loaded document: /home/schorpp/Projects/dvb/cubieboard_outline_2012-08-08_v1.1.dxf

:-)

Can open "Drawing Exchange DXF 12 or 2000" Format *.dxf only, not *.dwg .

y
tom

[thomas schorpp]

Am 15.09.2013 20:15, schrieb Alejandro Mery:
> On 14/09/13 02:50, thomas schorpp wrote:
>> Am 14.09.2013 00:07, schrieb Alejandro Mery:
>>> http://dl.cubieboard.org/hardware/ has all you need to make your
>>> daughter board that is not generic to all A10 or A20.

Cubieboard
http://dl.cubieboard.org/hardware/cubieboard_schematic_2012-08-08.pdf , p.1,p.11.

has got the (CSI0/)TS0 bus controls (A20 Balls E/D/22/23) N.C.,
but (CSI1/)TS1 bus controls and TWI1 connected to U15 p.11,

is this correct for in production board revisions?

I may need an extra GPIO pin for the Philips CU1216(-MKIII)'s special reset timing requirement,
Olimex A20 micro has got the RESET_N on GPIO-2, PIN 40, I'll try that first to init the receiver,
no RESET on Cubieboard GPIO connectors seen.

y
tom

[Jens Thiele]

thomas schorpp <thomas....@gmail.com> writes:

> Am 18.09.2013 10:50, schrieb Jens Thiele:
>> thomas schorpp <thomas....@gmail.com> writes:
>>
>>> and remember the massive EMC impact on my VDR host at my try to power
>>> my SATA HDD from the Olimex A10/20 rev.B 5V connection place on my
>>> rev.C board, I reported in IRC, what could get you the FCC FEDs (DE
>>> BnetzA) knocking on Your door with a 1000US$ fine :D
>>
>> can you explain in more detail to a hardware noob, please? is only rev.B
>> effected? (having rev c and d here)
>> maybe off-list and in german if you prefer
>
> Sorry, English is mandatory here and others may want to get my answer
> to this, too,

no problem

> and there's no individual personal user support from OSS- projects to
> prefer:

was just meant as offer

> Nothing is affected if You don't try my individual fun lab experiments
> at home.

ok, then i misread - thanks

[Henrik Nordström]

tor 2013-09-19 klockan 06:44 +0200 skrev thomas schorpp:

> Cubieboard
> http://dl.cubieboard.org/hardware/cubieboard_schematic_2012-08-08.pdf , p.1,p.11.
>
> has got the (CSI0/)TS0 bus controls (A20 Balls E/D/22/23) N.C.,
> but (CSI1/)TS1 bus controls and TWI1 connected to U15 p.11,

Cubieboard is meant to have TS1 fully available, but is not verified as
there have been no hardware or drivers to verify with.

What exactly do you need to connect your Philips CU1216(-MKIII)?

> is this correct for in production board revisions?

As far as I know that schematics applies to current Cubieboards, with
changes only in board layout to correct mistakes there.

> I may need an extra GPIO pin for the Philips CU1216(-MKIII)'s special reset timing requirement,

There is many free GPIO pins you can use.

> Olimex A20 micro has got the RESET_N on GPIO-2, PIN 40, I'll try that first to init the receiver,
> no RESET on Cubieboard GPIO connectors seen.

RESET_N is the system reset line. If you want separate reset control
then you need to use an GPIO.

Regards
Henrik

[thomas schorpp]

Am 19.09.2013 09:46, schrieb Henrik Nordstr�m:
> tor 2013-09-19 klockan 06:44 +0200 skrev thomas schorpp:
>
>> Cubieboard
>> http://dl.cubieboard.org/hardware/cubieboard_schematic_2012-08-08.pdf , p.1,p.11.
>>
>> has got the (CSI0/)TS0 bus controls (A20 Balls E/D/22/23) N.C.,
>> but (CSI1/)TS1 bus controls and TWI1 connected to U15 p.11,
>
> Cubieboard is meant to have TS1 fully available, but is not verified as
> there have been no hardware or drivers to verify with.

Try mine and setup the register for TS1 port.

>
> What exactly do you need to connect your Philips CU1216(-MKIII)?

http://read.pudn.com/downloads138/sourcecode/others/589797/CU1216L-3-datasheet.pdf , p.5

The TS0x PINs and TWI0 SDA/CLK (Olimex) for Tuner and Demod I2C
with correct I2C /AS /MIN adressing.

TS0 and TWI0 usage seems to breaks compatibility with Cubieboard,
TS1 only and TWI0 looks like internal use, TWI1 looks like Olimex internal.

I will use Olimex connection and driver setup first, then add module parameters
for TWI I2C and TS input selection.

>
>> is this correct for in production board revisions?
>
> As far as I know that schematics applies to current Cubieboards, with
> changes only in board layout to correct mistakes there.
>
>> I may need an extra GPIO pin for the Philips CU1216(-MKIII)'s special reset timing requirement,
>
> There is many free GPIO pins you can use.

Not so many on Cubieboard and not on the same connector like TS1x, needs a fully connected PCB
daughterboard to start.

>
>> Olimex A20 micro has got the RESET_N on GPIO-2, PIN 40, I'll try that first to init the receiver,
>> no RESET on Cubieboard GPIO connectors seen.
>
> RESET_N is the system reset line. If you want separate reset control
> then you need to use an GPIO.

Hmm, yes, and CU1216 "RST" PIN 26 looks TTL high level active, needs an inverter then.

We'll see, p.7, Anti- latch-up- Requirement B) should already be met by the boards power + reset circuit,
for C) the 3.3V lane of the board cannot be used because my 1.8V REG may have got a mismatching setup delay,
I need an extra 3.3V regulator with a delay circuit, but I'll try without, modern regulators setup very fast, if not
a little cap may do the trick cheaply, if not, there're better application schematics around ;-)

>
> Regards
> Henrik
>

y
tom

[Wolfgang Wegner]

On Thu, Sep 19, 2013 at 08:15:31PM +0200, thomas schorpp wrote:
>
> We'll see, p.7, Anti- latch-up- Requirement B) should already be met by
> the boards power + reset circuit,
> for C) the 3.3V lane of the board cannot be used because my 1.8V REG may
> have got a mismatching setup delay,
> I need an extra 3.3V regulator with a delay circuit, but I'll try without,
> modern regulators setup very fast, if not
> a little cap may do the trick cheaply, if not, there're better application
> schematics around ;-)

AFAIR, CU1216 is less critical in this respect - TU1216 definitely has
problems when power sequencing is not correct. The misbehaviour was not as
easy to recognize as a simple latch-up, I2C access showed no problems.
Being able to do a reset of the demod on driver request is sometimes
helpful for CU1216, IIRC, so I would use a GPIO to control the frontend
reset pin.

Best regards,
Wolfgang

[thomas schorpp]

Thanks for the report.

As I know my driver writing skills I'll have to reset the whole board on
"misbehaviour" far more often than "sometimes" anyway :D

y
tom