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 >> >(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. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.