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

[Michal Simek]

On 10.11.2016 13:08, Olliver Schinagl wrote:
> 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.

Can you give me that link to these patches?

Thanks,
Michal