[U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Olliver Schinagl]

Hi Michal,

On 10-11-16 12:37, Michal Simek wrote:
> On 8.11.2016 16:54, Olliver Schinagl wrote:
>> 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.
> Yes, Zynq and ZynqMP is using this feature. I am also aware about using
> qspi OTP region for storing information like this.
I saw, which triggered me here. What the Znyq currently does it uses its 
own private CONFIG setting:

+int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
+{
+#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
+    defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
+    defined(CONFIG_ZYNQ_EEPROM_BUS)
+       i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
+
+       if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
+                       CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
+                       ethaddr, 6))
+               printf("I2C EEPROM MAC address read failed\n");
+#endif
+
+       return 0;
+}

which are ZNYQ specific. In my patchset I give them very generic names 
as they can be used by anybody really.

Once Maxime's patches have merged and stabilized, i'd even say to switch 
over to the eeprom framework.
>
> Thanks,
> Michal
>
>