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.

How to send patches via git-send-email

In the past I either directly commited to git or send - if needed - my patches to e.g. mailing list by exporting the patches from my local git repo via 'git format-patch -s origin' and then importing them into my mailer. Yesterday I finally found some time to get git-send-email running to do this for me directly on command line.

First you have to choose if you always use the same email account to send your patches. In this case you need to configure 'git-send-email' this way:

git config --global sendemail.from "YOUR NAME <user@example.org>"
git config --global sendemail.smtpserver imap.example.org
git config --global sendemail.smtpuser USER
# depending on your config you may also set:
git config --global sendemail.smtpencryption tls

If you don't want to enter password for your SMTP server all the time:

git config --global sendemail.smtppass = PASS

If you use different settings/email accounts for different project, you can setup different identities for them. Here one example for btrfs project:

git config --global sendemail.btrfs.to "linux-btrfs@vger.kernel.org"
git config --global sendemail.btrfs.from "YOUR NAME <user@example.org>"
git config --global sendemail.btrfs.smtpserver imap.example.org
git config --global sendemail.btrfs.smtpuser USER
git config --global sendemail.btrfs.smtppass = PASS
git config --global sendemail.btrfs.smtpencryption tls

There are some other options you may should use as e.g.:

git config --global sendemail.chainreplyto false

to set the threading format to shallow/flat instead of the deep threading, which is much more readable on a mailing list if you send multiple patches at once.

Now you can send you patches with (you may have to replace origin with the revision you need):

git send-email --annotate origin

If you use an identity e.g.:

git send-email --identity=btrfs --annotate origin

If you didn't commit your changes into your local git branch with the -s option (to get the 'Signed-off-by:' line) you need to add the --signoff option, as I realized after sending my latest patches to the btrfs mailing list. If you send a patch series you may also want to use a cover email to explain something or to write more info. In this case you can use --cover-letter to get git to create and let you edit such an email before sending. 

Here the full example command I would use to send my patches:

git send-email --identity=btrfs --annotate --cover-letter --signoff origin

For more info check e.g. the Git Community Book or use your favorite internet search engine.

Some fixes for btrfs-progs ...

Yesterday I found some time to send some patches for btrfs-progs upstream. Unfortunately the information on the btrfs wiki pages about the source code repositories are completely outdated, either the repo didn't exist or the branch wasn't there as in case of the 'for-chris' branch of the 'Integration repository'. Finally I send them against the repo of Chris Mason listed at git.kernel.org. 

The patches fix some possible segfaults and some compiler warnings, you can find them at the mailing list.

CHERRY STRAIT Exclusive Testa Motari Edition

I got a 'CHERRY STRAIT Exclusive Testa Motari Edition' keyboard at Christmas from my girlfriend. It's a really exclusive keyboard. The top of the board is made out of wood veneer. Since each wood is unique as a fingerprint, no keyboard looks like the other. My keyboard was made with satin walnut, but you can get them also with vavona burl or macassar ebony. The veneer used is certified for sustainable forestry and no tropical wood was used.

The keyboard was derived from the 'CHERRY STRAIT Corded'. The wood was glued to a aluminium plate. Thanks to that detail the 'Testa Motari Edition' is much more torsion-resistant and not that wibbly-wobbly as the original keyboard was reported in some tests (e.g. here).

It's a really cool keyboard with a nice to touch surface. As you can see in the following pictures, the device is very flat. From the ergonomical point of view I miss a way to change the inclination, but it's comfortable to use anyway. I guess you have always to wash your hands before using it, since the wood isn't sealed or varnished.

The key layout needs getting used to: four of the five multimedia keys are on the top of the numeric pad but the 'Play'-key is located between the Print/SysRq key and F12.  Also the block between the main keys and the numeric pad is modified and the 'fn' keys are not grouped compared to a standard keyboard.

Résumé: It's an expensive but really nice keyboard! Thanks for the present!

Here some pictures (see more here):