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

[Robert Moskowitz]

First, I am a Linux abuser, not a developer compiler  ;)

I served my time doing OS dev back in the 80s.


On 12/26/2013 03:27 PM, Hans de Goede wrote:
> 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.

OK.  I am now officially lost.  Too many distros? mentioned here in one 
interrelated activity.  Remember, i just use Fedora/Centos to do things 
I need doing.  Not, hopefully, compiling code.

>
>>> -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 :|

I 'think' the CT does not have an otg usb, but it is good to know.

>
>>> -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).

So again, I build the SD card to boot and what kernel does it have, one 
from Fedora or one from sunxi?  I see an armhfp tree on the mirrors and 
assume that I will be able to get all that I need there once I get that 
SD card built.

>
>>>         * 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.

I hope you are using the local MAC address format?  Not grabing some 
OID, unless Allwinner has one assigned.  The likelihood of a collision 
is small, similar to what I do with HIP and our IPv6 prefix.  Please 
don't go using any old OID and hoping it will never get assigned or be 
seen again.  I should be able to find pointers to guidlines from the RAC 
if you need them.  BTW, most of my time in is 802.15; I am the chair of 
802.15.9, but I use to spend lots of time in 802.1 (.1X, .1AE, and .1AR).

>
> 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

And you can't do a firstboot operation to generate the random value to 
seed the MAC?  We are dealing with a number of 'challenges' from devices 
that do a bad job with MAC addresses.  Particularly as we get more 
bridging working in more places.  Expect it.

>
> 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).

Dirtft.

>
>
>>> 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

I will send this to the guy who said he could build a developers board 
for the additional ethernet ports.  See what he thinks.  I have not done 
stuff like this since I was dealing with 3com 3c501 cards!  (well on 
through 503 and 505 ;) ).
>
> 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.

Would be cheaper for the board, but then got to think about how other 
things will work out.