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