Hi,
On 25.11.2016 16:43, Olliver Schinagl wrote:
This patch-series introduces methods to retrieve the MAC address from an onboard EEPROM. The series does a few small cleanups at the start, as either I ran into them while doing this series and fixed them along the way or actually depended on them. If you want to split the smaller ones off into a smaller series I understand, but again, I do somewhat depend on them.
A manufacturer wants to produce boards and may even have MAC addresses for boards. Maintaining unique environments on a per-board basis however is horrible. Also this data should be very persistent, and not easily deletable by simply wiping the environment or device tree. Finally there are chips available on the market with a pre-programmed MAC address chips (proms) that a board manufacturer wants to use. Because of this, the MAC needs to be stored be able to read from such an 'external' source.
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 address.
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.
For the added tools, 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. To be able to replicate these tests the second series (which will be separate from this set) are needed.
Left TODO: If U-Boot configures eth0 and eth1 it inserts these values into the environment. If the fdt then has an ethernet alias for ethernet0, with a MAC address for a different device, lets say eth2) things will not work at so well. I guess that leaves some discussion with a separated improvement patch as a reliable way is needed to match actual u-boot detected devices, with fdt described devices. E.g. is dev->name the same name to the fdt? Can we blindly match here?
======= Changes since v3:
- Split off board specific stuff and only modify the generic functions
- Make reading of an eeprom available to every board. By default this is unconfigure and thus should just fall through
- Clean some minor bits up (ARP_HLEN) and use it more generically
- Update the gen_ethaddr_crc as suggested by simon
- Let the fixup_ethernet from fdt_common insert mac addresses to the
environment for unconfigured devices. There is a small caveat here however as described in the TODO above.
- Print the mac address that u-boot assigned to each device.
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.
I have tested this on zcu102 with mac in eeprom and it is working fine with one mac. I expect you have tested it with more and code looks good in this sense. I would personally prefer to know where that mac address is coming from in output.
Thanks, Michal