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

[Jagan Teki <jagannadh.teki@gmail.com>]

On Mon, May 15, 2017 at 6:17 PM, Tom Rini <trini@konsulko.com> wrote:
> 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.

Few of the patches need re-work, so updated patchwork status as
"Changes Requested" for the series.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.