On 04/11/2017 07:38 AM, o.schin...@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:
"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?
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
