[U-Boot] at91sam9g20 MAC address in EEPROM?
Hello everyone,
I am working on a product based on Atmel's sam9g20. Atmel's flashing procedure stores the MAC address as a u-boot environment variable (ethaddr).
We are not comfortable with storing the MAC address this way, and would rather keep it in EEPROM. Does anyone have experience with this?
Thanks, Jim
On Sat, Jul 10, 2010 at 7:53 AM, Jim Sheldon jims@russound.com wrote:
Hello everyone,
I am working on a product based on Atmel's sam9g20. Atmel's flashing procedure stores the MAC address as a u-boot environment variable (ethaddr).
We are not comfortable with storing the MAC address this way, and would rather keep it in EEPROM. Does anyone have experience with this?
Not on that chip, but we do it for Freescale PowerPC SOCs. Take a look at board/freescale/common/sys_eeprom.c
Jim Sheldon wrote:
Hello everyone,
I am working on a product based on Atmel's sam9g20. Atmel's flashing procedure stores the MAC address as a u-boot environment variable (ethaddr).
We are not comfortable with storing the MAC address this way, and would rather keep it in EEPROM. Does anyone have experience with this?
You can just connect an I2C EEPROM (At24C64 or such), define the necessary macros to access it. An exampe how to special read and set environment you can find in board/emk/common/vpd.c.
Reinhard
Dear Jim Sheldon,
In message 7941E07E1E020448937ACA7D4279E6327BAC64E468@powerhog you wrote:
I am working on a product based on Atmel's sam9g20. Atmel's flashing procedure stores the MAC address as a u-boot environment variable (ethaddr).
We are not comfortable with storing the MAC address this way, and would rather keep it in EEPROM. Does anyone have experience with this?
May I ask WHY you are not comfortable with using the U-Boot environment? Usually it's a very convenient place to store configuration data, and a pretty reliable one (especially when you use redundant environment).
I have seen _way_ more cases where data in EEPROM got lost than data loss from the environment.
Best regards,
Wolfgang Denk
Hello Mr. Denk,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Saturday, August 07, 2010 4:00 PM To: Jim Sheldon Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] at91sam9g20 MAC address in EEPROM?
Dear Jim Sheldon,
In message 7941E07E1E020448937ACA7D4279E6327BAC64E468@powerhog you wrote:
I am working on a product based on Atmel's sam9g20. Atmel's flashing
procedure stores the MAC address as a u-boot environment variable (ethaddr).
We are not comfortable with storing the MAC address this way, and
would rather keep it in EEPROM. Does anyone have experience with this?
May I ask WHY you are not comfortable with using the U-Boot environment? Usually it's a very convenient place to store configuration data, and a pretty reliable one (especially when you use redundant environment).
We're not concerned about u-boot's environment not being reliable, we just want the ability to completely erase the nand without worrying about losing essential data (like a MAC address). I suppose we could work around that area of the flash if/when erasing the nand is necessary, but then we would have to keep track of each environment variable that could be stored there.
I have seen _way_ more cases where data in EEPROM got lost than data loss from the environment.
That's discouraging, do you have any advice for where to store the MAC outside of nand, and not in an EEPROM?
Thanks for all your work on such a great open source bootloader! :)
Take care, Jim
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de A witty saying proves nothing, but saying something pointless gets people's attention.
Dear Jim Sheldon,
May I ask WHY you are not comfortable with using the U-Boot environment? Usually it's a very convenient place to store configuration data, and a pretty reliable one (especially when you use redundant environment).
We're not concerned about u-boot's environment not being reliable, we just want the ability to completely erase the nand without worrying about losing essential data (like a MAC address). I suppose we could work around that area of the flash if/when erasing the nand is necessary, but then we would have to keep track of each environment variable that could be stored there.
That is exactly my concern as well.
I have seen _way_ more cases where data in EEPROM got lost than data loss from the environment.
That's discouraging, do you have any advice for where to store the MAC outside of nand, and not in an EEPROM?
I cannot second that, we have always stored environment and vital product data in EEPROM (AT24C64). But VPD (includes MAC adresses) is never writen by u-boot; only read and made into respective setenv() variables. Check boards/emk/common/vpd.c for an idea.
Greetings, Reinhard
Dear Reinhard Meyer,
In message 4C600C3D.3060501@emk-elektronik.de you wrote:
We're not concerned about u-boot's environment not being reliable, we just want the ability to completely erase the nand without worrying about losing essential data (like a MAC address). I suppose we could work around that area of the flash if/when
erasing the nand is necessary, but then we would have to keep track of each environment variable that could be stored there.
That is exactly my concern as well.
I have seen _way_ more cases where data in EEPROM got lost than data loss from the environment.
That's discouraging, do you have any advice for where to store the MAC outside of nand, and not in an EEPROM?
I cannot second that, we have always stored environment and vital product data in EEPROM (AT24C64). But VPD (includes MAC adresses) is never writen by u-boot; only read and made into respective setenv() variables. Check boards/emk/common/vpd.c for an idea.
Most people think they are safe when they only read the EEPROM. They are under a misapprehension. If you reset the processor at the right time within a I2C read command, and if you (or your I2C controller) don't take special care, the next read access might cause a write operation on that device. See doc/I2C_Edge_Conditions for details.
Note that this is NOT a theoretical case. Many people have seen this. I had this myself with a customer who was switching to another, cheaper power supply. Upon power on, the voltage ramp up was relatively slow, which caused the system watchdog to reset the system 2 or 3 times because of too low voltages - and with 3 out of 5 power-ons the EEPROM content got corrupted.
If you need reliable read-only storage, use NOR.
Best regards,
Wolfgang Denk
participants (5)
-
Jim Sheldon -
Reinhard Meyer -
Reinhard Meyer -
Timur Tabi -
Wolfgang Denk