This patch-series introduces methods to retrieve the MAC address from an onboard EEPROM using the read_rom_hwaddr hook.
The reason we might want to read the MAC address from an EEPROM instead of storing the entire environment is mostly a size thing. Our default environment already is bigger then the EEPROM so it is understandable that someone might not give up the entire eeprom just for the u-boot environment. Especially if only board specific things might be stored in the eeprom (MAC, serial, product number etc). Additionally it is a board thing and a MAC address might be programmed at the factory before ever seeing any software.
The current idea of the eeprom layout, is to skip the first 8 bytes, so that other information can be stored there if needed, for example a header with some magic to identify the EEPROM. Or equivalent purposes.
After those 8 bytes the MAC address follows the first macaddress. The macaddress is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following the first macaddress one can store a second, or a third etc etc mac addresses.
The CRC8 is optional (via a define) but is strongly recommended to have. It helps preventing user error and more importantly, checks if the bytes read are actually a user inserted address. E.g. only writing 1 macaddress into the eeprom but trying to consume 2.
Hans de Goede and I talked about retrieving the MAC from the EEPROM for sunxi based boards a while ago, but hopefully this patch makes possible to have something slightly more generic, even if only the configuration options. Additionally the EEPROM layout could be recommended by u-boot as well.
Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I started my work on one of these and tested the implementation with one of our own real MAC addresses.
What still needs disussing I think, is the patches that remove the 'setup_environment' function in board.c. I think we have put functionality in boards.c which does not belong. Injecting ethernet addresses into the environment instead of using the net_op hooks as well as parsing the fdt to get overrides from. I think especially this last point should be done at a higher level, if possible at all.
I explicitly did not use the wiser eth_validate_ethaddr_str(), eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful (dependancies) to get these functions into the tools. I would suggest to merge as is, and if someone wants to improve these simple tools to use these functions to happily do so.
These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use internally on our production systems since v2 of this patch set.
As a recommendation, I would suggest for the zynq to adopt the config defines, as they are nice and generic and suggest to also implement the 8 byte offset, crc8 and pad bytes.
P.S. I have gotten in depth/familiar with PATMAN yet :)
======= Changes since v2: * Drop the id byte altogether and just mark it as reserved. The 'index' can be used to indicate the interface instead * Addopt the read_rom_hwaddr hooks * Renamed crc8 tool to gen_ethaddr_crc * Improved the layout EEPROM example * Made a function out of the hwaddress writing function in sunxi_emac so it can be re-used as the write_hwaddr net_ops hook. * No longer handle fdt parameters in board.c
Changes since v1: * Do not CRC the id byte, move it just after the crc byte. One of the reasons I decided to move it after the crc8 was mostly due to mass generation of MAC + CRC combo's where the ID is still unknown. Also not crc-ing the ID means that it is much easier for a user to change it (via the u-boot i2c cmd line or from within linux) without having to worry about the crc. * Add a generator to convert a MAC address from the input to a MAC + CRC8 on the output.