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

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

...

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/