[U-Boot-Users] why eeprom vs flash

[U-Boot-Users] why eeprom vs flash

[Jon Smirl]

I'm new to working on low level code like u-boot. Something I don't
understand is why things like the Ethernet address are stored in
eeprom instead of flash. Is this something to do with how boards are
manufactured? From a high level perspective it doesn't seem to matter
if eeprom or flash is used.

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] why eeprom vs flash

[David Hawkins]

Jon Smirl wrote:
> I'm new to working on low level code like u-boot. Something I don't
> understand is why things like the Ethernet address are stored in
> eeprom instead of flash. Is this something to do with how boards are
> manufactured? From a high level perspective it doesn't seem to matter
> if eeprom or flash is used.

I think you'll find varied implementations.

For example, on the MPC8349EA-MDS-PB boards, the
MAC addresses are stored in U-Boot environment variables
and they're written on the CPU heatsink base.

If you erase the Flash, then poof, gone are your MAC
addresses. When you Flash a new version of U-Boot you
need to set the IP addresses and save the environment
to the Flash.

I would imagine some designers prefer saving these type
of parameters to an EEPROM, independent of the application
(bootloader, kernel, filesystem, etc) flash. This would
cut down on the support calls from customers who erase
their flash and forget their MAC addresses (or can't
see the MAC labels if the units are installed).

So, as the designer, its up to you. But keep in mind that
you want to make it hard for a customer to screw up, so
a separate EEPROM could be a good choice.

Cheers,
Dave

[U-Boot-Users] why eeprom vs flash

[Mike Frysinger]

On Thursday 14 February 2008, Jon Smirl wrote:
> I'm new to working on low level code like u-boot. Something I don't
> understand is why things like the Ethernet address are stored in
> eeprom instead of flash. Is this something to do with how boards are
> manufactured? From a high level perspective it doesn't seem to matter
> if eeprom or flash is used.

most MACs have a small eeprom attached to it to specifically store the MAC 
address.  consult the datasheet for your MAC.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080214/9c5691f3/attachment.pgp 

[U-Boot-Users] why eeprom vs flash

[Jon Smirl]

On 2/14/08, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Jon Smirl wrote:
>  > I'm new to working on low level code like u-boot. Something I don't
>  > understand is why things like the Ethernet address are stored in
>  > eeprom instead of flash. Is this something to do with how boards are
>  > manufactured? From a high level perspective it doesn't seem to matter
>  > if eeprom or flash is used.
>
>
> I think you'll find varied implementations.
>
>  For example, on the MPC8349EA-MDS-PB boards, the
>  MAC addresses are stored in U-Boot environment variables
>  and they're written on the CPU heatsink base.
>
>  If you erase the Flash, then poof, gone are your MAC
>  addresses. When you Flash a new version of U-Boot you
>  need to set the IP addresses and save the environment
>  to the Flash.
>
>  I would imagine some designers prefer saving these type
>  of parameters to an EEPROM, independent of the application
>  (bootloader, kernel, filesystem, etc) flash. This would
>  cut down on the support calls from customers who erase
>  their flash and forget their MAC addresses (or can't
>  see the MAC labels if the units are installed).

How are the MAC addresses assigned? So if I order ten Ethernet chips
from Digikey will they come with something from the manufacturer
indicating which MAC addresses to use?
Or do I need to register as a vendor and get my own block of addresses?

>  So, as the designer, its up to you. But keep in mind that
>  you want to make it hard for a customer to screw up, so
>  a separate EEPROM could be a good choice.
>
>  Cheers,
>  Dave
>
>


-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] why eeprom vs flash

[Wolfgang Denk]

In message <9e4733910802141038h16afb653l8b6c8a0181ea109f@mail.gmail.com> you wrote:
> I'm new to working on low level code like u-boot. Something I don't
> understand is why things like the Ethernet address are stored in
> eeprom instead of flash. Is this something to do with how boards are

This may have h/w design reasons. For example, you may want  to  have
things  like  serial  number,  MAC address and other similar settings
stick with a device even when you change  the  CPU  module;  in  such
situations it's much easier to place a EEPROM somewhere in the device
itself;  with  a I2C bus you need only 3 wires. If you try to use NOR
flash in a similar configuration, you have to route the full data and
address bus and some other signals, which is much more expensive.

> manufactured? From a high level perspective it doesn't seem to matter
> if eeprom or flash is used.

Well, it does matter. Flash is much more reliable. Read  for  example
doc/I2C_Edge_Conditions  what  can (and does!) happen to I2C attached
EEPROM devices. And with flash, we can even  store  the  data  redun-
dantly, so you have really good reliability.

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 at denx.de
Making files is easy under  the  UNIX  operating  system.  Therefore,
users  tend  to  create  numerous  files  using large amounts of file
space. It has been said that the only standard thing about  all  UNIX
systems  is  the  message-of-the-day  telling users to clean up their
files.                            -- System V.2 administrator's guide

[U-Boot-Users] why eeprom vs flash

[Edward Jubenville]

Jon Smirl wrote:
> How are the MAC addresses assigned? So if I order ten Ethernet chips
> from Digikey will they come with something from the manufacturer
> indicating which MAC addresses to use?
> Or do I need to register as a vendor and get my own block of addresses?

If you are designing your own board in relatively low quantities, you might
want to look at Maxim chip DS2502-E48.  It holds a guaranteed unique
Ethernet MAC address, and would save you the hassle and cost of registering
to get your own address block.  The chip uses the Dallas/Maxim 1-wire
interface which I don't think u-boot supports (at least, not at the time),
so I wrote a u-boot standalone bit-bang program to print the MAC address,
and I manually set ethaddr in the u-boot environment.

Ed Jubenville

[U-Boot-Users] why eeprom vs flash

[Jerry Van Baren]

Jon Smirl wrote:
> On 2/14/08, David Hawkins <dwh@ovro.caltech.edu> wrote:
>> Jon Smirl wrote:
>>  > I'm new to working on low level code like u-boot. Something I don't
>>  > understand is why things like the Ethernet address are stored in
>>  > eeprom instead of flash. Is this something to do with how boards are
>>  > manufactured? From a high level perspective it doesn't seem to matter
>>  > if eeprom or flash is used.
>>
>>
>> I think you'll find varied implementations.
>>
>>  For example, on the MPC8349EA-MDS-PB boards, the
>>  MAC addresses are stored in U-Boot environment variables
>>  and they're written on the CPU heatsink base.
>>
>>  If you erase the Flash, then poof, gone are your MAC
>>  addresses. When you Flash a new version of U-Boot you
>>  need to set the IP addresses and save the environment
>>  to the Flash.
>>
>>  I would imagine some designers prefer saving these type
>>  of parameters to an EEPROM, independent of the application
>>  (bootloader, kernel, filesystem, etc) flash. This would
>>  cut down on the support calls from customers who erase
>>  their flash and forget their MAC addresses (or can't
>>  see the MAC labels if the units are installed).
> 
> How are the MAC addresses assigned? So if I order ten Ethernet chips
> from Digikey will they come with something from the manufacturer
> indicating which MAC addresses to use?

No, MAC chips don't come with MAC addresses, they are assigned by the 
board manufacturer, not the chip manufacture (to the best of my experience).

People have talked about buying 10 cheap ethernet boards and "stealing" 
their MAC addresses, but that is poor form because your board will be 
identified as belonging to a cheap NE2000 clone manufacturer.  :-/

FAQ:
<http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress>

You can set the "locally administered" bit to make your own MAC address 
(no guarantee of uniqueness, but pretty good odds if you are smart):
   <http://en.wikipedia.org/wiki/MAC_address>

"Universally administered and locally administered addresses are 
distinguished by setting the second least significant bit of the most 
significant byte of the address. If the bit is 0, the address is 
universally administered. If it is 1, the address is locally 
administered. The bit is 0 in all OUIs. For example, 02-00-00-00-00-01. 
The most significant byte is 02h. The binary is 00000010 and the second 
least significant bit is 1. Therefore, it is a locally administered 
address."


> Or do I need to register as a vendor and get my own block of addresses?

That is an option for a "small fee":
<http://standards.ieee.org/regauth/oui/pilot-ind.html>
<http://standards.ieee.org/regauth/oui/forms/>

>>  So, as the designer, its up to you. But keep in mind that
>>  you want to make it hard for a customer to screw up, so
>>  a separate EEPROM could be a good choice.
>>
>>  Cheers,
>>  Dave

Best regard,
gvb

[U-Boot-Users] why eeprom vs flash

[Wolfgang Denk]

In message <47B48CD0.9060600@ovro.caltech.edu> you wrote:
>
> I would imagine some designers prefer saving these type
> of parameters to an EEPROM, independent of the application
> (bootloader, kernel, filesystem, etc) flash. This would

Most of the designes I've seen so far then decided to use the  EEPROM
to  store  the  U-Boot environment, because then they didn't need any
special code to maintain the MAC addresses in  EEPROM.  That's  avery
bad decision, of course.

> So, as the designer, its up to you. But keep in mind that
> you want to make it hard for a customer to screw up, so
> a separate EEPROM could be a good choice.

In many cases it ain't. I've seen many board which lost their  EEPROM
contents,  typically because of edge condition problems as documented
in the file mentioned before - a poor power supply with too slow rise
times of the voltages makes an excellent test case. I know of systems
where it blows the EEPROM content in 2 out of 3 boot cycles :-(

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 at denx.de
He is truly wise who gains wisdom from another's mishap.

[U-Boot-Users] why eeprom vs flash

[Andrew Dyer]

On Thu, Feb 14, 2008 at 1:36 PM, Edward Jubenville
<edjubenville@adelphia.net> wrote:
>  If you are designing your own board in relatively low quantities, you might
>  want to look at Maxim chip DS2502-E48.  It holds a guaranteed unique
>  Ethernet MAC address, and would save you the hassle and cost of registering
>  to get your own address block.  The chip uses the Dallas/Maxim 1-wire
>  interface which I don't think u-boot supports (at least, not at the time),
>  so I wrote a u-boot standalone bit-bang program to print the MAC address,
>  and I manually set ethaddr in the u-boot environment.

We have code in our local tree (a bit hackish) to talk to this part
and use it to grab the MAC address.  I think someone else posted
something similar to the mailing list a while back.  We have since
switched to using our own block of MAC addresses serialized into flash
during production.  If someone wants it to play with and polish up,
let me know.

As for the EEPROMs, a lot of the ugliness can be traced to the two and
three wire busses used to talk to most of them (there used to be
parallel EEPROM, dunno anymore).  I believe the EEPROM cells inside
that actually store bits are perfectly reliable.  If there was a good
way of making the write 'atomic' you could make allowances for the
system level issues.

-- 
Hardware, n.:
 The parts of a computer system that can be kicked.

[U-Boot-Users] why eeprom vs flash

[David Hawkins]

>> So, as the designer, its up to you. But keep in mind that
>> you want to make it hard for a customer to screw up, so
>> a separate EEPROM could be a good choice.
> 
> In many cases it ain't. I've seen many board which lost their  EEPROM
> contents,  typically because of edge condition problems as documented
> in the file mentioned before - a poor power supply with too slow rise
> times of the voltages makes an excellent test case. I know of systems
> where it blows the EEPROM content in 2 out of 3 boot cycles :-(

Interesting failure mode.

In the case of say the MPC8349EA, it can use an I2C EEPROM as
the boot sequencer. So if a board design really needed to
use that mode, one would need to pay attention to the
above issue - independently of whether this same EEPROM was
used to store MAC addresses or serial numbers, etc.

An example EEPROM for the boot sequencer would be the AT24C512B.
Looking at its data sheet, there is a RESET MEMORY sequence
that could be used by the processor every time it booted
to ensure that the EEPROM was not left in a write-state.
I doubt the boot sequencer does this, so that would only
be a solution for storage of the environment in the EEPROM.
A better solution, is that the part also has a write-protect
pin, which can be controlled by a GPIO. If the GPIO is
tri-stated on power-up (likely), then a pull-up on the
pin can ensure that the part can not be written to
in error.

How slow is 'too slow' for a power-supply rise time?
(doc/I2C_Edge_Conditions doesn't mention).

To ensure correct power-supply sequencing, I use hot-swap
controllers (on cPCI power supply inputs), dc-to-dc converters
with programmable turn on times and slew-rates (for PPC/FPGA
core voltages, and DDR voltages), and linear regulators with
slew-rate controls. I've got most of them set to about 5-10ms.
The PowerPC docs state it can handle about 20ms between
all supplies, while the FPGAs want under 100ms, with
monotonic ramps on them all.

I doubt that I'll see this issue, but its an interesting
problem to be aware of.

Cheers,
Dave

PS. If anyone is interested, the power supply design notes,
and board design is here:
http://www.ovro.caltech.edu/~dwh/carma_board/