Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-12-09 Thread Joe Hershberger 
On Fri, Dec 2, 2016 at 4:12 AM, Olliver Schinagl  wrote:
> Hey Joe,
>
>
>
> On 30-11-16 21:00, Joe Hershberger wrote:
>>
>> On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl 
>> wrote:
>>>
>>> This patch allows Kconfig to enable and set parameters to make it
>>> possible to read the MAC address from an EEPROM. The net core layer then
>>> uses this information to read MAC addresses from this EEPROM.
>>>
>>> Besides the various tuneables as to how to access the eeprom (bus,
>>> address, addressing mode/length, 2 configurable that are EEPROM generic
>>> (e.g. SPI or some other form of access) which are:
>>>
>>> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
>>> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
>>> for other purposes (header MAGIC for example).
>>>
>>> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
>>> checksum that should be verified.
>>>
>>> Currently only I2C eeproms have been tested and thus only those options
>>> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
>>> just as created and added.
>>>
>>> The code currently first checks if there is a non-zero MAC address in
>>> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
>>> used by a board to supply the MAC in other ways.
>>>
>>> If both these fails, the other code is still in place to query the
>>> environent, which then can be used to override the hardware supplied
>>> data.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   doc/README.enetaddr | 99
>>> +
>>>   include/net.h   | 14 
>>>   net/Kconfig | 59 +++
>>>   net/eth-uclass.c|  9 +++--
>>>   net/eth_common.c| 34 ++
>>>   net/eth_legacy.c|  2 ++
>>>   6 files changed, 214 insertions(+), 3 deletions(-)
>>>

...

>>> diff --git a/net/eth_common.c b/net/eth_common.c
>>> index 079be89..e0d8b62 100644
>>> --- a/net/eth_common.c
>>> +++ b/net/eth_common.c
>>> @@ -8,10 +8,44 @@
>>>
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include "eth_internal.h"
>>>
>>> +int eeprom_read_enetaddr(const int index, unsigned char *enetaddr)
>>> +{
>>> +   uint8_t eeprom[ARP_HLEN + 1] = { 0x00 };
>>> +#if defined(CONFIG_NET_ETHADDR_EEPROM) &&
>>> defined(CONFIG_NET_ETHADDR_EEPROM_I2C)
>>
>> Since it is easily reasonable that SPI PROM is a likely useful
>> support, why not keep the layout stuff separate from the I2C stuff so
>> that it is trivial to plug in a different bus later? It will also make
>> the code clearer by untangling these.
>
>
> I strongly agree, but I recommend a follow up patch series (and thus merge
> this as is for now) to use Maxime's EEPROM framework patches. So then this
> gets replaced by simple read from eeprom.
>
> So yes, I have contemplated in splitting it up now and have a simply
> read_from_i2c() kind of function, I figured this gets solved elsewhere
> anyway.
>
> Additionally, the layout stuff would ideally be replaced by Igor (i think it
> was) eeprom layout framework (if those two combine) which solves both
> problems in one go.
>
> Or you want to see it split now as the other is a bad plan (tm)?

It's fine to wait if there is a plan going forward with a dependency
that might make this throw-away work.

> Olliver
>
>>
>>> +   int old_i2c_bus;
>>> +
>>> +   old_i2c_bus = i2c_get_bus_num();
>>> +   if (old_i2c_bus != CONFIG_NET_ETHADDR_EEPROM_I2C_BUS)
>>> +   i2c_set_bus_num(CONFIG_NET_ETHADDR_EEPROM_I2C_BUS);
>>> +   /* Skip in blocks of 8 (ARP + CRC8 + pad), but read 7 from the
>>> eeprom */
>>> +   if (i2c_read(CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR,
>>> +CONFIG_NET_ETHADDR_EEPROM_OFFSET + (index *
>>> (ARP_HLEN + 2)),
>>> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDRLEN,
>>> +eeprom, ARP_HLEN + 1)) {
>>> +   i2c_set_bus_num(old_i2c_bus);
>>> +   puts("Could not read the EEPROM or EEPROM missing on
>>> device: ");
>>> +   return -ENOSYS;
>>> +   }
>>> +   i2c_set_bus_num(old_i2c_bus);
>>> +
>>> +#ifdef CONFIG_NET_ETHADDR_EEPROM_CRC8
>>> +   if (crc8(0, eeprom, ARP_HLEN) != eeprom[ARP_HLEN]) {
>>> +   puts("CRC error on MAC address from EEPROM on device: ");
>>> +   return -EINVAL;
>>> +   }
>>> +#endif
>>> +#endif
>>> +
>>> +   memcpy(enetaddr, eeprom, ARP_HLEN);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>   void eth_parse_enetaddr(const char *addr, uchar *enetaddr)
>>>   {
>>>  char *end;
>>> diff --git a/net/eth_legacy.c b/net/eth_legacy.c
>>> index bf4de37..8fb5844 100644
>>> --- a/net/eth_legacy.c
>>> +++ b/net/eth_legacy.c
>>> @@ -136,6 +136,8 @@ int eth_write_hwaddr(struct eth_device *dev, const
>>> char *base_name,
>>>  unsigned char

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-12-02 Thread Olliver Schinagl 

Hey Joe,


On 30-11-16 21:00, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
  doc/README.enetaddr | 99 +
  include/net.h   | 14 
  net/Kconfig | 59 +++
  net/eth-uclass.c|  9 +++--
  net/eth_common.c| 34 ++
  net/eth_legacy.c|  2 ++
  6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
  Previous behavior had the MAC address always being programmed into hardware
  in the device's init() function.

+
+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various methods, but
+currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
+defaults to the very common 0x50. Small size EEPROM's generally use single byte
+addressing but larger EEPROM's may use double byte addressing, which can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, allowing
+the first 8 bytes to be used for an optional data, for example a configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the following
+example layout, this can be achieved.
+
+struct mac_addr {
+   uint8_t mac[ARP_HLEN];
+   uint8_t crc8;
+   uint8_t reserved;
+};
+
+struct config_eeprom {
+   uint32_t magic;
+   uint8_t version;
+   uint8_t reserved[2];
+   uint8_t mac_cnt;
+   struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+   .magic = { 'M', 'g', 'i', 'c' },
+   .reserved = { 0x00, 0x00 },
+   .mac_cnt = 2,
+   .mac_addr = {
+   {
+   .mac = {
+   0x01, 0x23, 0x45,
+   0x67, 0x89, 0xab,
+   },
+   .crc8 = 0xbe,
+   .reserved = 0x00,
+   }, {
+   .mac = {
+   0xba, 0x98, 0x76,
+   0x54, 0x32, 0x10,
+   },
+   .crc8 = 0x82,
+   .reserved = 0x00,
+   },
+   },
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-30 Thread Joe Hershberger 
On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer then
> uses this information to read MAC addresses from this EEPROM.
>
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM generic
> (e.g. SPI or some other form of access) which are:
>
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
> for other purposes (header MAGIC for example).
>
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
> checksum that should be verified.
>
> Currently only I2C eeproms have been tested and thus only those options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
>
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
>
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  doc/README.enetaddr | 99 
> +
>  include/net.h   | 14 
>  net/Kconfig | 59 +++
>  net/eth-uclass.c|  9 +++--
>  net/eth_common.c| 34 ++
>  net/eth_legacy.c|  2 ++
>  6 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
> index 50e4899..89c1f7d 100644
> --- a/doc/README.enetaddr
> +++ b/doc/README.enetaddr
> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
>  Previous behavior had the MAC address always being programmed into hardware
>  in the device's init() function.
>
> +
> + EEPROM
> +
> +
> +Boards may come with an EEPROM specifically to store configuration bits, such
> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
> +Depending on the board, the EEPROM may be connected on various methods, but
> +currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
> +
> +The following config options are available,
> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
> present.
> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
> +defaults to the very common 0x50. Small size EEPROM's generally use single 
> byte
> +addressing but larger EEPROM's may use double byte addressing, which can be
> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
> +
> +Within the EEPROM, the MAC address can be stored on any arbitrary offset,
> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, 
> allowing
> +the first 8 bytes to be used for an optional data, for example a 
> configuration
> +struct where the mac address is part of.
> +
> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
> +bytes. Whether to check this CRC8 or not is dependent on
> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
> +
> +To keep things nicely aligned, a final 'reserved' byte is added to the mac
> +address + crc8 combo.
> +
> +A board may want to store more information in its eeprom, using the following
> +example layout, this can be achieved.
> +
> +struct mac_addr {
> +   uint8_t mac[ARP_HLEN];
> +   uint8_t crc8;
> +   uint8_t reserved;
> +};
> +
> +struct config_eeprom {
> +   uint32_t magic;
> +   uint8_t version;
> +   uint8_t reserved[2];
> +   uint8_t mac_cnt;
> +   struct mac_addr[mac_cnt];
> +};
> +
> +Filling this in:
> +struct config_eeprom eeprom = {
> +   .magic = { 'M', 'g', 'i', 'c' },
> +   .reserved = { 0x00, 0x00 },
> +   .mac_cnt = 2,
> +   .mac_addr = {
> +   {
> +   .mac = {
> +   0x01, 0x23, 0x45,
> +   0x67, 0x89, 0xab,
> +   },
> +   .crc8 = 0xbe,
> +   .reserved = 0x00,
> +   }, {
> +   .mac = {
> +   0xba, 0x98, 0x76,
> +   0x54, 0x32, 0x10,
> +   },
> +   .crc8 = 0x82,
> +   .reserved = 0x00,
> +   },
> +   },
> +};
> +
> +The eeprom content would look like this.
> +
> +  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
> +0010  ba 98 76 54 32 10 82 00  |..vT2...|
> +
> +This can be done from linux using the i2c-tools:
> +
> +i2cset I2CBUS 0x50 0x08 0x01
> +i2cset I2CBUS 0x50 0x09 0x23
> +i2cset I2CBUS 0x50 0x0a

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-30 Thread Joe Hershberger 
On Wed, Nov 30, 2016 at 2:10 AM, Olliver Schinagl  wrote:
> Hey Michal,
>
>
>
> On 29-11-16 19:54, Michal Simek wrote:
>>
>> On 29.11.2016 17:45, Olliver Schinagl wrote:
>>>
>>> Hey Michal,
>>>
>>>
>>> On 28-11-16 09:21, Michal Simek wrote:

 On 25.11.2016 16:30, Olliver Schinagl wrote:
>
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer
> then
> uses this information to read MAC addresses from this EEPROM.
>
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM generic
> (e.g. SPI or some other form of access) which are:
>
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before the
> MAC
> for other purposes (header MAGIC for example).
>
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a
> CRC8-CCIT
> checksum that should be verified.
>
> Currently only I2C eeproms have been tested and thus only those options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
>
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
>
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
>
> Signed-off-by: Olliver Schinagl 
> ---
>doc/README.enetaddr | 99
> +
>include/net.h   | 14 
>net/Kconfig | 59 +++
>net/eth-uclass.c|  9 +++--
>net/eth_common.c| 34 ++
>net/eth_legacy.c|  2 ++
>6 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
> index 50e4899..89c1f7d 100644
> --- a/doc/README.enetaddr
> +++ b/doc/README.enetaddr
> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address
> (summarized):
>Previous behavior had the MAC address always being programmed into
> hardware
>in the device's init() function.
>+
> + EEPROM
> +
> +
> +Boards may come with an EEPROM specifically to store configuration
> bits, such
> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this
> feature.
> +Depending on the board, the EEPROM may be connected on various
> methods, but
> +currently, only the I2C bus can be used via
> CONFIG_NET_ETHADDR_EEPROM_I2C.
> +
> +The following config options are available,
> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom
> is present.
> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM,
> which
> +defaults to the very common 0x50. Small size EEPROM's generally use
> single byte
> +addressing but larger EEPROM's may use double byte addressing, which
> can be
> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
> +
> +Within the EEPROM, the MAC address can be stored on any arbitrary
> offset,
> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default
> however, allowing
> +the first 8 bytes to be used for an optional data, for example a
> configuration
> +struct where the mac address is part of.
> +
> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous
> ARP_HLEN
> +bytes. Whether to check this CRC8 or not is dependent on
> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
> +
> +To keep things nicely aligned, a final 'reserved' byte is added to
> the mac
> +address + crc8 combo.
> +
> +A board may want to store more information in its eeprom, using the
> following
> +example layout, this can be achieved.
> +
> +struct mac_addr {
> +uint8_t mac[ARP_HLEN];
> +uint8_t crc8;
> +uint8_t reserved;
> +};
> +
> +struct config_eeprom {
> +uint32_t magic;
> +uint8_t version;
> +uint8_t reserved[2];
> +uint8_t mac_cnt;
> +struct mac_addr[mac_cnt];
> +};
> +
> +Filling this in:
> +struct config_eeprom eeprom = {
> +.magic = { 'M', 'g', 'i', 'c' },
> +.reserved = { 0x00, 0x00 },
> +.mac_cnt = 2,
> +.mac_addr = {
> +{
> +.mac = {
> +0x01, 0x23, 0x45,
> +0x67, 0x89, 0xab,
> +},
> +.crc8 = 0xbe,
> +.reserved = 0x00,
> +

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-30 Thread Michal Simek 
On 30.11.2016 09:10, Olliver Schinagl wrote:
> Hey Michal,
> 
> 
> On 29-11-16 19:54, Michal Simek wrote:
>> On 29.11.2016 17:45, Olliver Schinagl wrote:
>>> Hey Michal,
>>>
>>>
>>> On 28-11-16 09:21, Michal Simek wrote:
 On 25.11.2016 16:30, Olliver Schinagl wrote:
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer
> then
> uses this information to read MAC addresses from this EEPROM.
>
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM
> generic
> (e.g. SPI or some other form of access) which are:
>
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before
> the MAC
> for other purposes (header MAGIC for example).
>
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a
> CRC8-CCIT
> checksum that should be verified.
>
> Currently only I2C eeproms have been tested and thus only those
> options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
>
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
>
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
>
> Signed-off-by: Olliver Schinagl 
> ---
>doc/README.enetaddr | 99
> +
>include/net.h   | 14 
>net/Kconfig | 59 +++
>net/eth-uclass.c|  9 +++--
>net/eth_common.c| 34 ++
>net/eth_legacy.c|  2 ++
>6 files changed, 214 insertions(+), 3 deletions(-)
>
> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
> index 50e4899..89c1f7d 100644
> --- a/doc/README.enetaddr
> +++ b/doc/README.enetaddr
> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address
> (summarized):
>Previous behavior had the MAC address always being programmed into
> hardware
>in the device's init() function.
>+
> + EEPROM
> +
> +
> +Boards may come with an EEPROM specifically to store configuration
> bits, such
> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this
> feature.
> +Depending on the board, the EEPROM may be connected on various
> methods, but
> +currently, only the I2C bus can be used via
> CONFIG_NET_ETHADDR_EEPROM_I2C.
> +
> +The following config options are available,
> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom
> is present.
> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM,
> which
> +defaults to the very common 0x50. Small size EEPROM's generally use
> single byte
> +addressing but larger EEPROM's may use double byte addressing, which
> can be
> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
> +
> +Within the EEPROM, the MAC address can be stored on any arbitrary
> offset,
> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default
> however, allowing
> +the first 8 bytes to be used for an optional data, for example a
> configuration
> +struct where the mac address is part of.
> +
> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous
> ARP_HLEN
> +bytes. Whether to check this CRC8 or not is dependent on
> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
> +
> +To keep things nicely aligned, a final 'reserved' byte is added to
> the mac
> +address + crc8 combo.
> +
> +A board may want to store more information in its eeprom, using the
> following
> +example layout, this can be achieved.
> +
> +struct mac_addr {
> +uint8_t mac[ARP_HLEN];
> +uint8_t crc8;
> +uint8_t reserved;
> +};
> +
> +struct config_eeprom {
> +uint32_t magic;
> +uint8_t version;
> +uint8_t reserved[2];
> +uint8_t mac_cnt;
> +struct mac_addr[mac_cnt];
> +};
> +
> +Filling this in:
> +struct config_eeprom eeprom = {
> +.magic = { 'M', 'g', 'i', 'c' },
> +.reserved = { 0x00, 0x00 },
> +.mac_cnt = 2,
> +.mac_addr = {
> +{
> +.mac = {
> +0x01, 0x23, 0x45,
> +0x67, 0x89, 0xab,
> +},
> +.crc8 = 0xbe,
> +.reserved = 0x00,
> +}, {
> +.mac = {
> +

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-30 Thread Olliver Schinagl 

Hey Michal,


On 29-11-16 19:54, Michal Simek wrote:

On 29.11.2016 17:45, Olliver Schinagl wrote:

Hey Michal,


On 28-11-16 09:21, Michal Simek wrote:

On 25.11.2016 16:30, Olliver Schinagl wrote:

This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
   doc/README.enetaddr | 99
+
   include/net.h   | 14 
   net/Kconfig | 59 +++
   net/eth-uclass.c|  9 +++--
   net/eth_common.c| 34 ++
   net/eth_legacy.c|  2 ++
   6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address
(summarized):
   Previous behavior had the MAC address always being programmed into
hardware
   in the device's init() function.
   +
+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration
bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various
methods, but
+currently, only the I2C bus can be used via
CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom
is present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM,
which
+defaults to the very common 0x50. Small size EEPROM's generally use
single byte
+addressing but larger EEPROM's may use double byte addressing, which
can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary
offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default
however, allowing
+the first 8 bytes to be used for an optional data, for example a
configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous
ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to
the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the
following
+example layout, this can be achieved.
+
+struct mac_addr {
+uint8_t mac[ARP_HLEN];
+uint8_t crc8;
+uint8_t reserved;
+};
+
+struct config_eeprom {
+uint32_t magic;
+uint8_t version;
+uint8_t reserved[2];
+uint8_t mac_cnt;
+struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+.magic = { 'M', 'g', 'i', 'c' },
+.reserved = { 0x00, 0x00 },
+.mac_cnt = 2,
+.mac_addr = {
+{
+.mac = {
+0x01, 0x23, 0x45,
+0x67, 0x89, 0xab,
+},
+.crc8 = 0xbe,
+.reserved = 0x00,
+}, {
+.mac = {
+0xba, 0x98, 0x76,
+0x54, 0x32, 0x10,
+},
+.crc8 = 0x82,
+.reserved = 0x00,
+},
+},
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00
|Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+
+u-boot> mm.b 0
+: 00 ? 01
+0001: 23 ? 23
+0002: 45 ? 45
+0003: 67 ? 67
+0004: 89 ? 89
+0005: ab ? ab

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-29 Thread Michal Simek 
On 29.11.2016 17:45, Olliver Schinagl wrote:
> Hey Michal,
> 
> 
> On 28-11-16 09:21, Michal Simek wrote:
>> On 25.11.2016 16:30, Olliver Schinagl wrote:
>>> This patch allows Kconfig to enable and set parameters to make it
>>> possible to read the MAC address from an EEPROM. The net core layer then
>>> uses this information to read MAC addresses from this EEPROM.
>>>
>>> Besides the various tuneables as to how to access the eeprom (bus,
>>> address, addressing mode/length, 2 configurable that are EEPROM generic
>>> (e.g. SPI or some other form of access) which are:
>>>
>>> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
>>> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
>>> for other purposes (header MAGIC for example).
>>>
>>> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
>>> checksum that should be verified.
>>>
>>> Currently only I2C eeproms have been tested and thus only those options
>>> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
>>> just as created and added.
>>>
>>> The code currently first checks if there is a non-zero MAC address in
>>> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
>>> used by a board to supply the MAC in other ways.
>>>
>>> If both these fails, the other code is still in place to query the
>>> environent, which then can be used to override the hardware supplied
>>> data.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   doc/README.enetaddr | 99
>>> +
>>>   include/net.h   | 14 
>>>   net/Kconfig | 59 +++
>>>   net/eth-uclass.c|  9 +++--
>>>   net/eth_common.c| 34 ++
>>>   net/eth_legacy.c|  2 ++
>>>   6 files changed, 214 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
>>> index 50e4899..89c1f7d 100644
>>> --- a/doc/README.enetaddr
>>> +++ b/doc/README.enetaddr
>>> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address
>>> (summarized):
>>>   Previous behavior had the MAC address always being programmed into
>>> hardware
>>>   in the device's init() function.
>>>   +
>>> + EEPROM
>>> +
>>> +
>>> +Boards may come with an EEPROM specifically to store configuration
>>> bits, such
>>> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
>>> +Depending on the board, the EEPROM may be connected on various
>>> methods, but
>>> +currently, only the I2C bus can be used via
>>> CONFIG_NET_ETHADDR_EEPROM_I2C.
>>> +
>>> +The following config options are available,
>>> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom
>>> is present.
>>> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM,
>>> which
>>> +defaults to the very common 0x50. Small size EEPROM's generally use
>>> single byte
>>> +addressing but larger EEPROM's may use double byte addressing, which
>>> can be
>>> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
>>> +
>>> +Within the EEPROM, the MAC address can be stored on any arbitrary
>>> offset,
>>> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default
>>> however, allowing
>>> +the first 8 bytes to be used for an optional data, for example a
>>> configuration
>>> +struct where the mac address is part of.
>>> +
>>> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous
>>> ARP_HLEN
>>> +bytes. Whether to check this CRC8 or not is dependent on
>>> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
>>> +
>>> +To keep things nicely aligned, a final 'reserved' byte is added to
>>> the mac
>>> +address + crc8 combo.
>>> +
>>> +A board may want to store more information in its eeprom, using the
>>> following
>>> +example layout, this can be achieved.
>>> +
>>> +struct mac_addr {
>>> +uint8_t mac[ARP_HLEN];
>>> +uint8_t crc8;
>>> +uint8_t reserved;
>>> +};
>>> +
>>> +struct config_eeprom {
>>> +uint32_t magic;
>>> +uint8_t version;
>>> +uint8_t reserved[2];
>>> +uint8_t mac_cnt;
>>> +struct mac_addr[mac_cnt];
>>> +};
>>> +
>>> +Filling this in:
>>> +struct config_eeprom eeprom = {
>>> +.magic = { 'M', 'g', 'i', 'c' },
>>> +.reserved = { 0x00, 0x00 },
>>> +.mac_cnt = 2,
>>> +.mac_addr = {
>>> +{
>>> +.mac = {
>>> +0x01, 0x23, 0x45,
>>> +0x67, 0x89, 0xab,
>>> +},
>>> +.crc8 = 0xbe,
>>> +.reserved = 0x00,
>>> +}, {
>>> +.mac = {
>>> +0xba, 0x98, 0x76,
>>> +0x54, 0x32, 0x10,
>>> +},
>>> +.crc8 = 0x82,
>>> +.reserved = 0x00,
>>> +},
>>> +},
>>> +};
>>> +
>>> +The eeprom content would look like this.
>>> +
>>> +  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00
>>> |Mgic.#Eg|
>>> +0010  ba 98 76 54 32 10 82 00

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-29 Thread Olliver Schinagl 

Hey Michal,


On 28-11-16 09:21, Michal Simek wrote:

On 25.11.2016 16:30, Olliver Schinagl wrote:

This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
  doc/README.enetaddr | 99 +
  include/net.h   | 14 
  net/Kconfig | 59 +++
  net/eth-uclass.c|  9 +++--
  net/eth_common.c| 34 ++
  net/eth_legacy.c|  2 ++
  6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
  Previous behavior had the MAC address always being programmed into hardware
  in the device's init() function.
  
+

+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various methods, but
+currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
+defaults to the very common 0x50. Small size EEPROM's generally use single byte
+addressing but larger EEPROM's may use double byte addressing, which can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, allowing
+the first 8 bytes to be used for an optional data, for example a configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the following
+example layout, this can be achieved.
+
+struct mac_addr {
+   uint8_t mac[ARP_HLEN];
+   uint8_t crc8;
+   uint8_t reserved;
+};
+
+struct config_eeprom {
+   uint32_t magic;
+   uint8_t version;
+   uint8_t reserved[2];
+   uint8_t mac_cnt;
+   struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+   .magic = { 'M', 'g', 'i', 'c' },
+   .reserved = { 0x00, 0x00 },
+   .mac_cnt = 2,
+   .mac_addr = {
+   {
+   .mac = {
+   0x01, 0x23, 0x45,
+   0x67, 0x89, 0xab,
+   },
+   .crc8 = 0xbe,
+   .reserved = 0x00,
+   }, {
+   .mac = {
+   0xba, 0x98, 0x76,
+   0x54, 0x32, 0x10,
+   },
+   .crc8 = 0x82,
+   .reserved = 0x00,
+   },
+   },
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+
+u-boot> mm.b 0
+: 00 ?

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-28 Thread Michal Simek 
On 25.11.2016 16:30, Olliver Schinagl wrote:
> This patch allows Kconfig to enable and set parameters to make it
> possible to read the MAC address from an EEPROM. The net core layer then
> uses this information to read MAC addresses from this EEPROM.
> 
> Besides the various tuneables as to how to access the eeprom (bus,
> address, addressing mode/length, 2 configurable that are EEPROM generic
> (e.g. SPI or some other form of access) which are:
> 
> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
> for other purposes (header MAGIC for example).
> 
> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
> checksum that should be verified.
> 
> Currently only I2C eeproms have been tested and thus only those options
> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
> just as created and added.
> 
> The code currently first checks if there is a non-zero MAC address in
> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
> used by a board to supply the MAC in other ways.
> 
> If both these fails, the other code is still in place to query the
> environent, which then can be used to override the hardware supplied
> data.
> 
> Signed-off-by: Olliver Schinagl 
> ---
>  doc/README.enetaddr | 99 
> +
>  include/net.h   | 14 
>  net/Kconfig | 59 +++
>  net/eth-uclass.c|  9 +++--
>  net/eth_common.c| 34 ++
>  net/eth_legacy.c|  2 ++
>  6 files changed, 214 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/README.enetaddr b/doc/README.enetaddr
> index 50e4899..89c1f7d 100644
> --- a/doc/README.enetaddr
> +++ b/doc/README.enetaddr
> @@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
>  Previous behavior had the MAC address always being programmed into hardware
>  in the device's init() function.
>  
> +
> + EEPROM
> +
> +
> +Boards may come with an EEPROM specifically to store configuration bits, such
> +as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
> +Depending on the board, the EEPROM may be connected on various methods, but
> +currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
> +
> +The following config options are available,
> +CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
> present.
> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
> +defaults to the very common 0x50. Small size EEPROM's generally use single 
> byte
> +addressing but larger EEPROM's may use double byte addressing, which can be
> +configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
> +
> +Within the EEPROM, the MAC address can be stored on any arbitrary offset,
> +CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, 
> allowing
> +the first 8 bytes to be used for an optional data, for example a 
> configuration
> +struct where the mac address is part of.
> +
> +Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
> +bytes. Whether to check this CRC8 or not is dependent on
> +CONFIG_NET_ETHADDR_EEPROM_CRC8.
> +
> +To keep things nicely aligned, a final 'reserved' byte is added to the mac
> +address + crc8 combo.
> +
> +A board may want to store more information in its eeprom, using the following
> +example layout, this can be achieved.
> +
> +struct mac_addr {
> + uint8_t mac[ARP_HLEN];
> + uint8_t crc8;
> + uint8_t reserved;
> +};
> +
> +struct config_eeprom {
> + uint32_t magic;
> + uint8_t version;
> + uint8_t reserved[2];
> + uint8_t mac_cnt;
> + struct mac_addr[mac_cnt];
> +};
> +
> +Filling this in:
> +struct config_eeprom eeprom = {
> + .magic = { 'M', 'g', 'i', 'c' },
> + .reserved = { 0x00, 0x00 },
> + .mac_cnt = 2,
> + .mac_addr = {
> + {
> + .mac = {
> + 0x01, 0x23, 0x45,
> + 0x67, 0x89, 0xab,
> + },
> + .crc8 = 0xbe,
> + .reserved = 0x00,
> + }, {
> + .mac = {
> + 0xba, 0x98, 0x76,
> + 0x54, 0x32, 0x10,
> + },
> + .crc8 = 0x82,
> + .reserved = 0x00,
> + },
> + },
> +};
> +
> +The eeprom content would look like this.
> +
> +  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
> +0010  ba 98 76 54 32 10 82 00  |..vT2...|
> +
> +This can be done from linux using the i2c-tools:
> +
> +i2cset I2CBUS 0x50 0x08 0x01
> +i2cset I2CBUS 0x50 0x09 0x23
> +i2cset I2CBUS 0x50 0x0a 0x45
> +i2cset I2CBUS 0x50 0x0b 0x67
> +i2cset I2CBUS 0x50 0x0c 0x89
> +i2cset

[U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-25 Thread Olliver Schinagl 
This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
 doc/README.enetaddr | 99 +
 include/net.h   | 14 
 net/Kconfig | 59 +++
 net/eth-uclass.c|  9 +++--
 net/eth_common.c| 34 ++
 net/eth_legacy.c|  2 ++
 6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
 Previous behavior had the MAC address always being programmed into hardware
 in the device's init() function.
 
+
+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various methods, but
+currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
+defaults to the very common 0x50. Small size EEPROM's generally use single byte
+addressing but larger EEPROM's may use double byte addressing, which can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, allowing
+the first 8 bytes to be used for an optional data, for example a configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the following
+example layout, this can be achieved.
+
+struct mac_addr {
+   uint8_t mac[ARP_HLEN];
+   uint8_t crc8;
+   uint8_t reserved;
+};
+
+struct config_eeprom {
+   uint32_t magic;
+   uint8_t version;
+   uint8_t reserved[2];
+   uint8_t mac_cnt;
+   struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+   .magic = { 'M', 'g', 'i', 'c' },
+   .reserved = { 0x00, 0x00 },
+   .mac_cnt = 2,
+   .mac_addr = {
+   {
+   .mac = {
+   0x01, 0x23, 0x45,
+   0x67, 0x89, 0xab,
+   },
+   .crc8 = 0xbe,
+   .reserved = 0x00,
+   }, {
+   .mac = {
+   0xba, 0x98, 0x76,
+   0x54, 0x32, 0x10,
+   },
+   .crc8 = 0x82,
+   .reserved = 0x00,
+   },
+   },
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+
+u-boot> mm.b 0
+: 00 ? 01
+0001: 23 ? 23
+0002: 45 ? 45
+0003: 67 ? 67
+0004: 89 ? 89
+0005: ab ? ab
+0006: be ?