[U-Boot] [PATCHv6 00/28] Retrieve MAC address from EEPROM

[Tom Rini <trini@konsulko.com>]

On Mon, May 15, 2017 at 10:09:02AM +0200, Olliver Schinagl wrote:
> Hey all,
> 
> On 15-05-17 10:02, Olliver Schinagl wrote:
> >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.
> >
> >These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND
> >and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
> >internally on our production systems since v2 of this patch set.
> >
> >TODO in a follow up series:
> >* Replace the I2C specific read function to a generic function using
> >Maxime Ripard's EEPROM uclass once merged.
> >* Upgrade to use the EERPOM layout functionality as suggested by Igor Grinberg
> >* Add EEPROM/Mac commands suggested by York Sun
> >
> >The series was initially based ontop of Joe's u-boot_net/next branches, but I
> >rebased it ontop of u-boot/master to get the latest sunxi changes, including:
> >sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC
> >ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
> >
> >Which are on their way to being merged in master. So once those land into master
> >this all should apply cleanly. Sorry Joe!
> 
> So I accidentally added those too to this patch series as well
> (first two patches). Which are technically not part of this series
> and are on their way as it is. Does patchwork figure out this
> automatically, or do you prefer a resend with the 2 patches removed?

I've made patchwork reflect things correctly.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170515/e38cb692/attachment.sig>