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

York Sun york.sun at nxp.com
Tue Apr 11 15:32:44 UTC 2017


On 04/11/2017 07:38 AM, o.schinagl at ultimaker.com wrote:
> 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 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.
>
> 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?
>

The EEPROM we have holds more than just MAC addresses. It also has 
system ID, errata, number of ports, and CRC32 checksum. You can see them 
in cmd/mac.c, or board/freescale/common/sys_eeprom.c.

The command "mac" can read data out, and it can write. This is EEPROM on 
I2C bus. We were requested to provide a tool to update the errata number 
and etc.

York


More information about the U-Boot mailing list