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. Thanks, Michal _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot