PandaBoard: persistant MAC address via initrd

I worked out a solution to replace the random MAC address set by the smsc95xx kernel module with the MAC address generated by u-boot on the PandaBoard(ES). It should also work on the BeagleBoard.

As first you need this kernel patch to fix isses with exporting the assign type (PERM, RANDOM, STOLEN) to /sys/class/net/*/addr_assign_type correctly if the smsc95xx driver generate a random MAC address. Build your kernel, if you use openSUSE:Factory:ARM you can get RPMs here, until it's integrated into the official openSUSE kernel.

Now you need a mkinitrd with this patch or a you install these RPMs for openSUSE. This adds a initrd boot script to set the MAC address from kernel cmdline parameters. These are the available parameters and some example values:

• setmac.set_mac_addr=01:23:45:67:89:ab
• setmac.set_iface=eth0
• setmac.set_module=smsc95xx

The setmac.set_mac_addr= is mandatory to change the MAC and you have to choose one of the other two parameters. Either you specify the network interface or the kernel driver/module. In case you use setmac.set_module the first network device provided by this module which has a random MAC gets the new address assigned. Please note: this script change the MAC of a interface only if addr_assign_type=1 , otherwise nothing will change.

If you have installed the new kernel and mkinitrd you may need to follow these steps:

# mount the boot partition which contains the uImage (and may also the MLO file) 
mount /dev/mmcblk0p1 /mnt
# make sure this partition contains the new uImage
# build a new initrd
mkinitrd -B
# create a uInitrd
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd /mnt/uInitrd

Now you need to tell u-boot to boot from the uInitrd and to set the needed cmdline parameters. I prefer to use a uEnv.txt file instead of a boot.scr since you simply can change it without call mkimage. You can download my currently used uEnv.txt here. The content depends on your setup you may need to adapt yours:

bootargs=root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M omapfb.vram=0:16M

bootcmd=mmc rescan ; setenv bootargs ${bootargs} setmac.set_mac_addr="${usbethaddr}" setmac.set_iface=eth0; fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000

uenvcmd=boot

Now umount /mnt and reboot your system. If you already worked around the random MAC address problem: don't forget to remove/disable these hacks.

Update: PandaBoard persistent MAC from smsc95xx kernel module

Some days ago I decided to send an updated and reworked version of my kernel patch for the smsc95xx kernel module - to get a persistent MAC address via the kernel cmdline from u-boot - to the linux kernel mailing list. I should have known better and save me the time: the patch wasn't accepted. You can follow the discussion here.

If you follow the argumentation, we should drop the support for changing the MAC address of a network device via kernel module parameter also from e.g. the following modules: sunhme, fec or ksz884x. And we should then also remove all the 'generate a random MAC for real devices' since it all could be somehow get managed in the user-space, although it's pita to handle this task in user-space since it's currently even hard to find out if a device got a random MAC assigned from the kernel.

I still plan to add the patch to the openSUSE kernel until I've worked out another solution. Feel free to use the patch anyway on your system.

PandaBoard: get persistent MAC address by default

The PandaBoard/PandaBoard ES, as the BeagleBoard too, don't have a EEPROM on the (USB-) network card to store the MAC address. That's why you get a new MAC and subsequently a new IP address with each boot. You can set the MAC manually via e.g. 'ifconfig eth0 hw ether 01:23:45:67:78:01' or also automatically via the network scripts.

The other solution would be to generate a MAC on OMAP (version > 2) machines by reusing another unique hardware identifier. There is already an old patch written by Mark Crichton for the BeagleBoard. And there was also an patch on the kernel mailing list from Andy Green and some related discussion, but none of them got into the kernel.  The problem was that if there are more than one card in the system without EEPROM they all would get the same MAC address. That sounds reasonable to me while I'm not sure that something like this will happen with a high chance out in the field. And since there are objections against exporting the OMAP die ID to the sysfs there is no simple way to handle the MAC generation in userspace (e.g. via udev).

While investigating how u-boot handle the no-EEPROM problem, I've found out that the u-boot code already contain functions to generate a persistent MAC for such devices. The MAC gets also exported to the u-boot environment as usbethaddr. That's why I wrote a patch for the smsc95xx kernel driver (based on a patch from Sebastien Jan) to take a module parameter to set the MAC address via the kernel command line. With this patch the driver takes the following parameter: macaddr=01:23:45:67:89:ab;[tgt-netdevname] and assign the given MAC address to the first device in the system without a MAC on the EEPROM. If there is more than one device without EEPROM you can add the netdevice name to the parameter - separated by a ';' - to assign it to a special device (e.g. for eth0: macaddr=01:23:45:67:89:ab;eth0). If there is no MAC given, the device still gets a random MAC as before.

After patching and installing your kernel, you need to change the u-boot config to pass the $usbethaddr from the environment along to the kernel cmdline. I used a uEnv.txt file (on my boot partition) instead of the legacy/obsolete boot.scr, since you simply can change the file without call mkimage after each change. That's the content of the uEnv.txt file I currently use to set the MAC of my PandaBoard ES:

bootargs=root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M omapfb.vram=0:16M

bootcmd=mmc rescan ; setenv bootargs ${bootargs} smsc95xx.macaddr="${usbethaddr}" ; fatload mmc 0 0x82000000 uImage; bootm 0x82000000

uenvcmd=boot

You can find the patch here, I plan to include it into the openSUSE OMAP2+ kernel and to send it upstream as soon as I have some reports back that it also works for others. You can find an kernel RPM for openSUSE Factory here.

Pandaboard ES: How to get 1 GByte RAM

Some colleagues told me they have only ~750 MByte RAM available on their PandaBoards.  So I checked my PandaBoard ES and it was the same there. As first I tried to set mem=1024M in boot.scr, but this didn't help. After some research I found that our kernel from the openSUSE:Factory:ARM repository wasn't build with HIGHMEM support. But the kernel need HIGHMEM-support to access the memory above 768MB on ARM/OMAP.


I changed the kernel config for the omap2plus package and build a new kernel RPM locally.

As soon as I installed the new kernel and rebooted, I got this:

root@pandboardES:/ # free 
             total  used   free shared buffers cached
Mem:       1010680 54604 956076      0    3516  29384
-/+ buffers/cache: 21704 988976
Swap:            0     0      0

I'll submit a new kernel package, but for now you can get the RPMs here.

PandaBoard ES ... got it up and running openSUSE

I finally found some time the last days to play with my new PandaBoard ES. As first Dirk Müller helped me by providing an image for my SD-card with an image that worked with the normal PandaBord. Thanks! Unfortunately we couldn't get the machine running with this image.

Later I tried a Linaro Android build and the machine booted. As I copied some of the files from the boot partition to the SD-card with the openSUSE installation it booted into openSUSE. After a hint from Alexander Graf (to change the console in u-boot to ttyO2) I could also access the serial console.

I could now play around and build on the board to find a fix for the openSUSE image Dirk provided to me: Since it didn't boot with the latest u-boot/x-loader git code from mainline, I tired the u-boot git from Linaro. This step finally solved the issue. I created a new u-boot package for openSUSE: u-boot-linaro-omap4panda. While the upstream u-boot package deletes the MLO file at the end of make, the Linaro u-boot doesn't. Therefore the new RPM should obsolete x-loader-omap4panda at openSUSE. 

You can get the Factory RPM (temporary) here. I already made a submit request for Base:System ... we will see if and when it gets in.

New PandaBoard ES arrived

Today finally my new PandaBoard ES arrived from Digi-Key. Here the new features compared to the former PandaBoard:

• Dual-core 1.2 GHz ARM® Cortex™-A9 MPCore™ (OMAP4460) with SMP from Texas Instruments
• provides 25% increase in graphics performance over OMAP4430 (but use a Imagination Technologies’ POWERVR™ SGX540 graphics core as the PandaBoard)
• DSI Support
• Bluetooth Low Energy Capable
• Sysboot switch available on board

The rest of the board should be the same as on the OMAP4430 based PandaBoard. Here some pictures:

Let's start to get an openSUSE running on the machine ... I'll post updates as soon as I found the time to play around with this tiny thing.