[fedora-arm] Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

Thu Dec 26 20:27:35 UTC 2013

Hi,

On 12/26/2013 02:44 PM, Robert Moskowitz wrote:
>
> On 10/13/2013 05:29 PM, Hans de Goede wrote:
>> Hi All,
>>
>> I'm very happy to announce the third release (r3) of my Fedora 19 ARM
>> remix images for Allwinner A10, A10s, A13 and A20 based devices. This
>> release is based on the official Fedora 19 Final for ARM images,
>> with u-boot and kernel(s) from the linux-sunxi project:
>> http://linux-sunxi.org/
>>
>> New this release:
>>
>> 1) Fix the bad brown paper bag bug in r2 which caused it to not boot
>> on sun4i (A10) and sun5i (A13/A10s) devices
>> 2) Support for the cubietruck (except for the wifi module)
>
> Will this get fixed in f19?  Or not until f20?

Given that F20 is out now, the next release of the respin will be
F-20 based. I don't plan to do much kernel work for this though, as my
main focus is on upstream kernel work, rather then on the android-3.4
kernel based linux-sunxi kernels.

>> -The regular (host not otg) usb-port on A10s based boards can be a
>>  bit quirky. It is best to plug in a hub even when using only one
>>  device, otherwise the device may not be recognized. If this happens,
>>  after adding a hub, often a power-cycle is needed too.
>
> Yet another reason to go with the A20.

Actually this is fixed in F-19 r3, but I forgot to remove it from the
known issues list :|

>> -The wifi chip on the Auxtek-T004 hdmi-stick and on the cubietruck are
>>  unsupported atm
>
> I am not hurrying out and buying a CT, and my first application will probably not use wifi, but eventually I will be needing this.

Good news, ct wifi seems to be working with upstream kernels. No idea what
this means for the sunxi-3.4 kernels, but if your application is headless,
then upstream kernels are already pretty good atm (if you build them
from the latest sunxi-devel sources).

>>         * If you've an A20 board, your ethernet may have a random mac-address,
>>           so if you want to configure a static ip-address and want it to stick
>>           across reboots, go to the ethernet-tab, select the mac-address field
>>           and delete its contents, so that the static ip address you're
>>           configuring does not get tied to the random mac-address.
>
> I work in IEEE 802.  This is NASTY!

Yep.

 > They did not want to get enough address space from the RAC?  I may have to get one just to figure out what is going on (and will talk to my colleagues in .1 at the Jan meeting.  This is probably more common than I would have thought).

So the story here is a bit longer then just this release note:

1) Almost all Allwinner A1x / A20 devices don't have an eeprom to store a MAC address

And I believe Allwinner considers this to be a problem of the OEM, not of their SoC,
with there tools to create images it is possible to put the MAC address in a file in
the /boot partition, but AFAIK no oems are actually doing that as they use a single
nand image for all boards of a certain model, and actually using this would require
modifying the nand image for each board before flashing the board.

2) For those few that do include an eeprom, there is no code to actually use this,
given 1.

3) As a workaround we usually derive a MAC address from the SID, the SID is a small
write once (we think) prom in the A1x / A20 which contains a "secure" device-id, of
which some bits are fixed (they indicate the SOC model and revision) and the rest
seems to be random, see:
http://linux-sunxi.org/SID_Register_Guide

So I've written a patch to use the random bits to get a (hopefully, not using assigned
addresses!) unique address, which is consistent over reboots.

4) But the first A20 SOCs did not have their SID proms written, so they were all 0, so
there the best we can do is generate a random MAC address each boot, so it won't be
consistent over reboots

5) Also uboot currently does not use the SID method to get a MAC address yet, someone
(me probably) needs to fix this, esp. since upstream kernels now inherit the MAC as
set by u-boot (through devicetree).

>> How to power your allwinner device
>> ----------------------------------
>>
>> For reliable operation it is important that your allwinner device is properly
>> powered. Some users try to power their allwinner development boards through
>> the power pin on the serial port / uart connector. This is a very bad idea!
>> and will almost always result in unreliable operation. Instaed always power
>> your allwinner device over the barrel connector intended for that using,
>> using a quality, reliable power supply.
>
> Good to know and will probably impact one solar powered project (if it gets funding).
>
>> Known Issues
>> ------------
>> * The broadcom sdio wifi found in the Auxtek T004 hdmi-stick and on the
>>   Cubietruck is not supported
>
> You really make sure we got the message.  ;)

He he, yeah, to be fair this is the README which I copy pasted to my announce mail
for completeness :)

>> Supported hardware components / features:
>> -----------------------------------------
>>
>> Fedora 19 ARM for Allwinner A10 supports the following components:
>> * SPI (as module, not supported on A20)
>
> Ooops.  I am looking at adding addtional ethernet ports using this. I see that there are a number of single ethernet port modules for SPI on Arnudio systems.  It seems this is a route to get the A20 to function as a multiport router.  Do you see this limitation being fixed?

Fixing this should be easy, it is likely just a question of:

1) Making sure the irq number is right (if it is hardcoded in the spi-driver,
rather then taken from plat/irqs.h it will be of by 32, the fix is to stop
hardcoding it and use the define from plat/irqs.h

2) Porting the dma code to dma-compat.h (to hide sun4i versus sun7i differences),
there are patches doing this to other drivers in the tree, those patches + the
sun7i allwinnner source drop together should make this easy.

Note there may already be (untested) patches for this in the list archives
I don't remember.

This is for the sunxi-3.4 kernel. I've no idea what the status of spi
support upstream is. Likely we first need support for the dma-controller
which is still to be written.

So summarizing depending on your exact use-case you may need to do some work
on either the upstream or 3.4 kernel to get the combination of peripherals
you want working to work. Again depending on your use-case it may be better
to just go with a non A20 device, ie the original cubieboard, where everything
will just work with the linux-sunxi 3.4 kernels.

Regards,

Hans