Hey York, On Mon, 2017-04-10 at 09:23 -0700, York Sun wrote: > On 04/10/2017 08:57 AM, Olliver Schinagl wrote: > > Hey York, > > > > On 10-04-17 17:52, York Sun wrote: > > > On 04/10/2017 08:34 AM, Olliver Schinagl wrote: > > > > First off: > > > > P.S. Joe, for some reason my previous patches where added with > > > > me as: > > > > "oli...@schinagl.nl <oli...@schinagl.nl>" I see that it comes > > > > from > > > > patchwork > > > > as such. Is there some way to fix this to > > > > "Olliver Schinagl <oli...@schinagl.nl>"? > > > > > > > > Below the updated summary: > > > > > > > > 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. > > > > > > > > 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 > > > > macaddress. > > > > > > > > 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. > > > > > > Interesting solution. We have used EEPROM to store board ID, > > > version > > > number, MAC addresses on many of our boards. We have a command > > > "mac" to > > > read/write these addresses. Would you take a look to see if it is > > > possible to integrate? > > > > I feel bad for not noticing the mac command! I think that this > > indeed > > could get integrated, providing generic helpers. > > > > Just wished you would have sent your suggestion during patch v1 or > > v2 :p > > > > Sorry, for some reason I wasn't CC'ed for your earlier version. They > were buried in thousands of emails.
Yeah, I saw, sorry. As for the do_mac cmd, It looks something useful to add, I'll do that once Maxime's EEPROM patches have landed as I will add support for that then. Also I want to use the generic eeprom layout stuff for the layout then and at that point, it would be good to integrate the do_mac stuff. The only thing I don't quite understand from looking at the code, is the name implies that you read/write/modify the MAC address in the rom with this, but I see that the two implementers have lots of other functions here, such as dumping the entire eeprom etc. So what is the intend of do_mac? only MAC address related things, or full rom related tasks? Olliver > > York > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
