On Mon, May 15, 2017 at 6:17 PM, Tom Rini <tr...@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
>> >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
>> >Following the first macaddress one can store a second, or a third etc etc
>> >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
>> >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
>> >* Add EEPROM/Mac commands suggested by York Sun
>> >The series was initially based ontop of Joe's u-boot_net/next branches, but
>> >rebased it ontop of u-boot/master to get the latest sunxi changes,
>> >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
>> >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.
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.