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

Thu Dec 26 22:09:18 UTC 2013

Hi,

On 12/26/2013 10:35 PM, Robert Moskowitz wrote:
> First, I am a Linux abuser, not a developer compiler  ;)

I see.

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

Fedora 20 (the successor to Fedora 19) is out. But the official Fedora
arm images do not support allwinner devices as the official Linux
kernel does not support allwinnner devices.

Allwinner has released sources to their own modified 3.4 kernel which
support allwinner devices. Since Allwinners sources are a bit of a mess
a community project has been started around these modified 3.4 sources.

I create and maintain Fedora ARM remix images based on these modified
community maintained 3.4 sources. The latest release of this remix
is still based on Fedora 19, it is Fedora 19 r3 (3th release of my remix),
I plan to do a Fedora 20 based version of the remix one of these days,
but I don't know exactly when.

This situation is not ideal, so various people are now working on getting
allwinnner devices in the official linux kernel, which should remove the
need for a respin when we release Fedora 21.

So I don't plan to do much work on the still 3.4 based kernel for the
Fedora 20 release of the remix, and thus support for the sdio wifi on
the cubietruck being in the Fedora 20 release of the remix is unlikely.

<snip>

>>>> -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 download the F-19 r3 allwinner remix, it will have the 3.4 kernel, as
will the F-20 remix if/when I release it. So no sdio wifi.

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

Yes I'm setting locally administrated bit to 1 (byte 0 to 0x02), the rest of the address
bytes are filled with the random bits from the SID.

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

I guess we could come up with something to only do the random generation once, but atm
there is no support for this since this situation is rather rare. Note that later A20
SoCs such as the one in the cubietruck (IIRC) do have the SID bits filled with a random
serial number, from which a fixed MAC address can be derived.

<snip>

Regards,

Hans