[U-Boot] [PATCH 00/14] [PATCHv4] Retrieve MAC address from EEPROM

[Michal Simek]

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