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.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
