[U-Boot] [PATCHv5 00/21] Retrieve MAC address from EEPROM

[o.schinagl at ultimaker.com <o.schinagl@ultimaker.com>]

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:
> > > > "oliver at schinagl.nl <oliver@schinagl.nl>" I see that it comes
> > > > from
> > > > patchwork
> > > > as such. Is there some way to fix this to
> > > > "Olliver Schinagl <oliver@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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot