From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Mon, 10 Apr 2017 08:52:26 -0700 Subject: [U-Boot] [PATCHv5 00/21] Retrieve MAC address from EEPROM In-Reply-To: <20170410153356.2664-1-oliver@schinagl.nl> References: <20170410153356.2664-1-oliver@schinagl.nl> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/10/2017 08:34 AM, Olliver Schinagl wrote: > First off: > P.S. Joe, for some reason my previous patches where added with me as: > "oliver at schinagl.nl " I see that it comes from patchwork > as such. Is there some way to fix this to > "Olliver Schinagl "? > > Below the updated summary: > > 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. Interesting solution. We have used EEPROM to store board ID, version number, MAC addresses on many of our boards. We have a command "mac" to read/write these addresses. Would you take a look to see if it is possible to integrate? York