From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 15 May 2017 08:47:09 -0400 Subject: [U-Boot] [PATCHv6 00/28] Retrieve MAC address from EEPROM In-Reply-To: <34fd744e-14cd-3ec1-473a-f20ca1caa075@schinagl.nl> References: <20170515080244.21345-1-oliver@schinagl.nl> <34fd744e-14cd-3ec1-473a-f20ca1caa075@schinagl.nl> Message-ID: <20170515124709.GY5701@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: