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

York Sun york.sun at nxp.com
Mon Apr 10 16:23:32 UTC 2017


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 at schinagl.nl>" I see that it comes from
>>> patchwork
>>> as such. Is there some way to fix this to
>>> "Olliver Schinagl <oliver at 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.

York



More information about the U-Boot mailing list