Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Hans de Goede]

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)
3) Support for the Megafeis A08 and Mini-X with A10s

You can download it here:
http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armh...

sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f

It is important to read the README, the image standard comes without
u-boot pre-loaded since u-boot is board specific. The image includes
a user-friendly simple script to install the right u-boot for
your board, but if you simply xzcat the image to an sdcard, and then
boot your device with the sdcard, things will *not* work.

See the README for a list of currently supported boards.

Known Issues:
-Many boards don't have an rtc (A10 and A20 have a builtin one),
  or at least no battery backup for it, resulting in the date
  + time being wrong.
-If the date is of by more then a couple of months, "yum update"
  won't work because certificate validation fails for the https
  connection yum tries to make. So if yum fails to get its repodata
  first check (and fix) your date
-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.
-The wifi chip on the Auxtek-T004 hdmi-stick and on the cubietruck are
  unsupported atm

Enjoy,

Hans


And to make sure everyone reads the README, let me print it here
in full:


Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README
-----------------------------------------------------------------

Quickstart guide
----------------

1) Insert an sdcard, note any data on the card will be destroyed!
2) Make sure the card is not mounted, run "mount" and if the card shows
    up in the output umount its partitions
3) Write the img file to the card, ie as root do:
    xzcat Fedora-19-a10-armhfp-r2.img.xz > /dev/mmcblk0
    sync
4) The card is not yet ready for use! Since the A10 u-boot is board
    specific, the image comes without any uboot install, follow the next
    steps to install the right u-boot for your board
5) Remove the card, and re-insert it. The uboot partition should get
    automatically mounted, if not mount it manually,
6) As root (or through sudo) run: <uboot-part-mount>/select-board.sh, ie:
    sudo /run/media/hans/uboot/select-board.sh

    If you've dialog installed the select-board.sh script will prompt for
    your board. If you don't have dialog installed, it will print the list
    of supported boards. Lookup your board and re-run the script with the
    shortname for your board as argument, ie:
    sudo sh /run/media/hans/uboot/select-board.sh mk802
7) umount the uboot and rootfs partitions, ie:
    umount /run/media/hans/uboot
    umount /run/media/hans/rootfs
8) Your sdcard is now ready for use
9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor
10) When first booting from the sdcard inserted Fedora will automatically
    reboot once, this is part of the process to resize the root partition to
    fill the entire sdcard and is normal behavior.
11) After the automatic reboot Fedora will start with the initial-setup wizard:
    11a) Configure networking, note:
         * If you've an A10 board with wired ethernet and you want to use dhcp
           you don't need to do anything.
         * 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.
    11b) Setup the time zone
    11c) Set a root password
    11d) Create a user
12) Log in as the just created user
13) Enjoy Fedora on your A10 device


Supported Devices:
------------------

Fedora 19 ARM for Allwinner A10 has been tested with the following devices:
* A10s-OLinuXino-MICRO (Olimex)
* A13-OLinuXino (Olimex)
* A13-OLinuXino-MICRO (Olimex)
* A20-OLinuXino-MICRO (Olimex)
* Auxtek T003 hdmi tv stick
* Auxtek T004 hdmi tv stick
* BA10 TV Box
* Cubieboard development board 1024 MB RAM
* Cubieboard2 (A20) development board
* Cubietruck development board
* Gooseberry development board
* Mele A1000G/A2000G 1024 MB RAM
* Mini-X 1024 MB RAM
* mk802 (with female mini hdmi) 512 MB RAM
* mk802 with A10s (s with a circle around it on the barcode label)
* mk802ii (with male normal hdmi) 1024 MB RAM
* r7 hdmi tv stick
* UHost U1A hdmi tv stick
* Wobo i5 TV Box

Fedora 19 ARM should also work on the following devices:
* A10 tablet sold under various names (whitelabel)
* A13 tablet sold under various names (whitelabel)
* Coby MID7042 tablet
* Coby MID8042 tablet
* Coby MID9742 tablet
* Cubieboard development board 512 MB RAM
* DNS AirTab M82 tablet
* EOMA68 A10 CPU card
* H6 netbook
* Hackberry development board
* Hyundai a7hd tablet
* iNet-97F Rev.2 (and clones) tablet
* Marsboard A10
* Megafeis A08
* Mele A1000/A2000 512 MB RAM
* Mele A3700
* Mini-X 512 MB RAM
* Mini-X with A10s soc
* mk802 (with female mini hdmi) 1024 MB RAM
* pcDuino development board
* Point of View ProTab 2 IPS 9" tablet
* Point of View ProTab 2 IPS tablet with 3g
* Sanei N90
* XZPAD700 7" tablet

Configuring the display output
------------------------------

Multiple video outputs at the same time are not supported. By default
hdmi output with EDID is used for all devices, except for tablets/netbooks
where the default output is the lcd.

The default hdmi output with EDID will get the native resolution of your
TV / monitor and use that. Note that in order for this to work your TV /
monitor must be connected *and turned on*, before booting your device.

The output resolution can be configured with the disp.screen0_output_mode
kernel cmdline value, which can be found in the extrargs part of uEnv.txt in
the uboot partition. The default uEnv.txt contains the following value:
disp.screen0_output_mode=EDID:1280x720p60

This means try to use EDID and if no valid EDID info is found fallback to
1280x720p60.

The used output can be changed by adding disp.screen0_output_type=X to the
extraargs in uEnv.txt. With X being one of: 0:none; 1:lcd; 2:tv; 3:hdmi; 4:vga

Some per display type notes:
-lcd outputs: Hardcoded to the native mode, disp.screen0_output_mode is ignored
-tv: For the cvbs output disp.screen0_output_mode must be set to one of the
  following: pal, pal-svideo, ntsc, ntsc-svideo, pal-m, pal-m-svideo, pal-nc,
  pal-nc-svideo. Note the -svideo variants should only be used on boards with
  an svideo connector, for composite out use the regular variants, ie:
  disp.screen0_output_type=2 disp.screen0_output_mode=pal
-hdmi: To override the EDID detected mode, drop the "EDID:" from the
  disp.screen0_output_mode value and set it to the desired mode, ie:
  disp.screen0_output_type=3 disp.screen0_output_mode=1360x768p60
-vga: Does not support EDID, "EDID:" must be removed from the
  disp.screen0_output_mode value otherwise it will be ignored. interlaced
  progressive and refreshrate settings specified are ignored, each resolution
  has hardcoded values for these. Example usage:
  disp.screen0_output_type=4 disp.screen0_output_mode=1024x768


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.


USB controller caveats
----------------------

The OTG USB controller in host mode only supports a limited number of
devices, plugging in a hub + mouse + keyboard typically will make either
the mouse or keyboard not work. This is a hardware limitation which we
will likely not be able to work around.

On tv-sticks and top-set boxes, simply avoid the otg connector, instead
use a hub in a regular host usb connector. Note on the mini-x the otg / host
marking is not always correct. If things don't work try using the OTG
connector instead!

On tablets and the gooseberry unfortunately only the otg connector is
available. One solution there is using a single usb-device which is
both a keyboard and a mouse at the same time. IE the receiver for logitech
wireless desktop sets.


Known Issues
------------
* The broadcom sdio wifi found in the Auxtek T004 hdmi-stick and on the
   Cubietruck is not supported


Supported hardware components / features:
-----------------------------------------

Fedora 19 ARM for Allwinner A10 supports the following components:
* CPU + PMU + RAM
* Serial ports
* MMC cards
* Internal NAND storage
* Framebuffer on lcd / vga / hdmi / composite video
* Sound both analog out and over hdmi
* OTG USB controller
* Both standard USB host controllers
* Wifi
* Wired Ethernet
* SATA
* IR (untested at this time)
* SPI (as module, not supported on A20)
* "tablet" keys on olinuxino boards
* 7 and 10 inch lcd displays on olinuxino boards (requires selecting the
   right config in select-board.sh


Unsupported hardware components:
--------------------------------

The following components require various proprietary blobs to be used, and
as such are not supported in the Fedora images. The kernel drivers for them
are present (usually as modules), so if you add the necessary blobs you might
get these to work:
* Mali 400 GPU
* Cedar hardware video & audio decoding and encoding engine
* G2D 2d engine

Note that the drivers for these need some memory to be reserved at boot, and
since they are not supported by default in the Fedora images, this memory
reservation has been disabled. To reserve the memory edit /boot/uEnv.txt and
remove the kernel cmdline options which disable the memory reservation.


Differences from stock Fedora
-----------------------------
* Since the A10 is not a very powerful soc some services which are enabled by
   default on Fedora are disabled in the image, see build-image.sh for a list.
* No plymouth: we log to a serial console for debugging so no pretty splash.
   Also we don't use an initrd, so removing the console=ttyS0,115200 from
   the extraargs in uEnv.txt will give plymouth, but so late it hardly matters.


Rebuilding the Fedora 19 ARM for Allwinner A10 disk image
---------------------------------------------------------

Building the Fedora 19 ARM for Allwinner A10 disk image consists of 2 steps
1) Building a uboot.tar.gz and rootfs.tar.gz "overlays", this is done
    bu the build-boot-root-sh script
2) Combining uboot.tar.gz and rootfs.tar.gz with an official Fedora 19 arm img,
    this combining is done by the build-image.sh script
    The a10 image you downloaded is based on Fedora-XFCE-armhfp-19-1-sda.raw

These scripts are hosted here:
https://github.com/jwrdegoede/sunxi-fedora-scripts.git

A copy of the exact versions of these scripts used to build this Fedora A10
image can be found in the scripts directory of the uboot partition, the
kernel config used during the build can be found here too.

If you want to exactly reproduce this image it is important to use the
scripts from the scripts dir of the uboot partition, as the scripts contain
GIT tags used during the build to checkout the exact versions to build.

The pre-conditions these scripts expect to be met, and the exact usage of
them is documented in comments in the top of each script.

[Jozef Mlich]

On Sun, 2013-10-13 at 23:29 +0200, Hans de Goede wrote:

>  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/
>  
>  http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armh...
>  
>  sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f 
Hi Hans,

great job! I am trying to test your image on Cubieboard with 1GB RAM. So
far, it was working quite good for me. I had the only trouble with yum
update. It seems the "mirrorlist" variable is not working. I was trying
to use baseurl instead. 

However, the default value wasn't working for me. There should be
fedora-secondary instead of fedora in url. 

http://download.fedoraproject.org/pub/fedora/linux/fedora-secondary/relea...

I am not sure if this is an issue for anyone else.

regards,
-- 
Jozef Mlich <jmlich(a)redhat.com&gt;
Associate Software Engineer - EMEA ENG Developer Experience
Mobile: [phone]
http://cz.redhat.com/
Red Hat, Inc.

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Thu, 31 Oct 2013 17:14:13 +0100
Jozef Mlich <jmlich(a)redhat.com&gt; escribió:
>  On Sun, 2013-10-13 at 23:29 +0200, Hans de Goede wrote:
>  
>  > 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/
>  > 
>  >
> http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armh...
>  > 
>  > sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f
>  
>  Hi Hans,
>  
>  great job! I am trying to test your image on Cubieboard with 1GB RAM.
>  So far, it was working quite good for me. I had the only trouble with
>  yum update. It seems the "mirrorlist" variable is not working. I was
>  trying to use baseurl instead. 
>  
if mirrorlist is not working its because ssl is failing to work
correctly because time on your system is wrong and outside whats valid
for the ssl cert, it is a known issue with the fix being to fix your
system time.

>  However, the default value wasn't working for me. There should
> be
>  fedora-secondary instead of fedora in url. 
>  
>
> http://download.fedoraproject.org/pub/fedora/linux/fedora-secondary/relea...
>  
This is due to the package being shared between primary and secondary
arches.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJScqaJAAoJEH7ltONmPFDR5+YQAKVoINYnegsw8wV3JlEauuix
> j9iIZKvHMYUEMygHLQKAC6W/qeTBVa1SOcwYtTicw3YtCmhrzMRbhJk+/X4QiAPV
> AwQywlUpPQsCYkxFZR+HrQkpw0ft4103ZngdU6BD+YFO+HZVZ33GayYO9R8fvdTe
> 3bWGiQgEhBNS6MDgW6fboe1G0SxxQ5chZHcdn/9H2JpnCz4HN2YtzcaCFzqJcPC9
> v+LSrP4a2+Dt58+fS9iKN3LD+qcynOeI9t+Dr47q7Mf27S6PyCpu5mcMDuLR7IYj
> UcaDx588dTdr0Hxv22Cb8pgoKSzjwxge5ajBwI1/scWn8n7oDUxZx+iGwd6YqFic
> FnwVO34Jef4mSU0X8qhthB4BB4gsBtorrtEj2po7CjMRIl0d+1BiILOqC770yn3A
> h1IQrLZcDdrhkd2jHlNy5cdfUI6q7FB2NEldQMM+SShwzloLtKRlYrKEnLHGU4Ad
> w9yX2aYcjoYADIkHFBm4JGgmJBPazAGPJB2GZTfATTTCZovtyAKubIQHUfUPHxyX
> 7cdgY9blipmNl+bXTqmeQHbvDrb+x0TzKXUIJhGhAUNuAptXKK7awQWnT4VYuKfH
> HIP2J4lwyaTUZmJo+aXrroxqGhzInMgg+Z87hLwD/1Ixo0t2ysyE9YAzwN69v1Oc
> N7P97uQdN4jbA7hkJUIb
> =bxUk
> -----END PGP SIGNATURE-----
>

Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Robert Moskowitz]

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?

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

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

>  Enjoy,
>
>  Hans 
Oh, I plan to.  Thanks.  But a couple more questions.

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

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

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


Thank you for your efforts.

Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Hans de Goede]

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

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.

Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Hans de Goede]

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

Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Peter Robinson]

h>>         * 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!  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). 
It's something that is very common in a lot of the ARM based dev
boards and not just limited to the Allwinner devices. Of the dozen or
so dev boards I have I'm aware that at least 3-4 of them have no set
MAC address. Basically because to store it they need to add a eeprom
to store the MAC to the BOM and they're aiming for bottom of the price
point for these devices basically it adds extra cost they don't want.

Peter

MAC addr - Re: Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Robert Moskowitz]

On 12/26/2013 05:09 PM, Hans de Goede wrote:
>  Hi,
>
>  On 12/26/2013 10:35 PM, Robert Moskowitz wrote:
>
> >>
> >>>>         * 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. 
I have to do some checking, but it SEEMed like MAC address was fixed 
across reboots as was IPv6 address (this is why I say this).  I will 
boot up my F19 and F20 images tomorrow to check this.  It would seem 
that at least with F19 and maybe F20, you still have the 
/etc/sysconfig/network-script/ifcfg-eth0 to put the MAC addr in? systemd 
seems to change these, and on my F20, each wifi connection has its own 
script (and what would that do with each ethernet 802.1X connection if 
you use that?).

Part of my interest is stable IPv6 addresses, and also I have built a 
Redsleeve install ontop of the F19 kernel and uboot.  Since these will 
be production systems, I really want stable MAC and IPv6 addresses.

MAC addr - Re: Cubietruck questions - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 3

[Robert Moskowitz]

On 08/09/2014 11:19 PM, Robert Moskowitz wrote:
>  On 12/26/2013 05:09 PM, Hans de Goede wrote:
> > Hi,
> >
> > On 12/26/2013 10:35 PM, Robert Moskowitz wrote:
> >
> >>>
> >>>>>         * 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.
>
>  I have to do some checking, but it SEEMed like MAC address was fixed 
>  across reboots as was IPv6 address (this is why I say this).  I will 
>  boot up my F19 and F20 images tomorrow to check this.  It would seem 
>  that at least with F19 and maybe F20, you still have the 
>  /etc/sysconfig/network-script/ifcfg-eth0 to put the MAC addr in? 
>  systemd seems to change these, and on my F20, each wifi connection has 
>  its own script (and what would that do with each ethernet 802.1X 
>  connection if you use that?).
>
>  Part of my interest is stable IPv6 addresses, and also I have built a 
>  Redsleeve install ontop of the F19 kernel and uboot. Since these will 
>  be production systems, I really want stable MAC and IPv6 addresses. 
I am getting a consistant, local scope MAC addr on my Cubieboard of:

02:c4:03:82:c1:53

I am assuming thus it is based on constant bits from the SID?  Both F19 
and F20 have this MAC and for multiple builds of F19.  I will have to 
check out what the F21 is doing.

So do you just construct this at each boot?  Is it in some file in /dev/ 
perhaps?  I do not see it anywhere in /etc/sysconfig

thanks.

I am thinking of handcrafting my MAC addr so I have control over my IPv6 
address for my production boxes.  I have been thinking what I have done 
todate to make my IPv6 static in DNS, and did not like it.  But if I can 
figure out a format for a local scope MAC, I can then let the IPv6 be 
built on it plus the PA provided prefix.  Makes multi-interface easier.