Unique MAC address without using a flash memory and without prompting the user?

Altera_Forum · ‎02-17-2013

Dear Sirs,

I am facing a little challenge with MAC addresses here. The default way of assigning a MAC address is by reading it from flash memory. Below is an example (from nios2eds/examples/software/web_server_rgmii/network_utilities.c):

error_t get_board_mac_addr(unsigned char mac_addr)
{
  error_t error = 0;
  alt_u32 signature;
  /* Get the flash sector with the MAC address. */
  error = FindLastFlashSectorOffset(&last_flash_sector_offset);
  if (!error)
    last_flash_sector = EXT_FLASH_BASE + last_flash_sector_offset;
/* This last_flash_sector region of flash is examined to see if 
 * valid network settings are present, indicated by a signature of 0x00005afe at 
 * the first address of the last flash sector.  This hex value is chosen as the 
 * signature since it looks like the english word "SAFE", meaning that it is 
 * safe to use these network address values.  
*/
  if (!error)
  {
    signature = IORD_32DIRECT(last_flash_sector, 0);
    if (signature != 0x00005afe)
    {
      error = generate_and_store_mac_addr();
    }
  }
  
  if (!error)
  {
    mac_addr = IORD_8DIRECT(last_flash_sector, 4);
    mac_addr = IORD_8DIRECT(last_flash_sector, 5);
    mac_addr = IORD_8DIRECT(last_flash_sector, 6);
    mac_addr = IORD_8DIRECT(last_flash_sector, 7);
    mac_addr = IORD_8DIRECT(last_flash_sector, 8);
    mac_addr = IORD_8DIRECT(last_flash_sector, 9);
    
    printf("Your Ethernet MAC address is %02x:%02x:%02x:%02x:%02x:%02x\n", 
            mac_addr,
            mac_addr,
            mac_addr,
            mac_addr,
            mac_addr,
            mac_addr);
  }
  return error;
}

If that fails, then a user is prompted for the board serial number to generate MAC address.

Is there any other way? What I am trying to do here is not to use a flash memory, and not to prompt the user for anything. My setup is the following:

1) Arria II GX 6G board

2) Marvell 88E1111 10/100/1000 PHY

3) TSE

4) Two streaming mSGDMA instances (one for read/one for write).

5) PCIe IP Core

The board is controlled by the host over PCIe.

I was wondering if there is some sort of unique PCIe device serial number, or maybe PHY has something unique in it so that I can access it using MDIO?

Any hints/ideas are very much appreciated.

Thanks!

Altera_Forum · ‎02-17-2013

Why not use a backup copy of the MAC?

Here's a few locations you could use;

1. If you only have one board, put the MAC in the FPGA image.

2. If you use multiple boards, put it in two places in the flash.

3. The MAX II CPLD has UFM (user flash memory). If you can communicate to the MAX II device, put a copy in UFM.

4. If the board has an I2C EEPROM, put a copy there.

Read the data sheet for the flash device on the board. Flash sometimes has options to protect sectors or to write to a One Time Program (OTP) section.

Having the software fall back on a single MAC is also ok if you are only using a few boards and expect only one board to be screwed up. If your boards get their IP addresses from DHCP, you could setup the DHCP server to send you an email if the fall-back MAC address is in use. That would allow you to ping the IP associated with the fall-back MAC and find out which one it is, eg., via a serial number ... that is stored in a different place to the MAC :)

Cheers,

Dave

PS. The Marvell PHY does not have a unique serial number, just a part ID code that is the same between parts.

Altera_Forum · ‎02-17-2013

Dave,

Thank you for your response! Yeah, not having a unique PHY ID is somewhat disappointing :) I am trying to avoid flashing the ID on the board because then I need to know a serial number of the board when programming it and I can't seem to find a way to query the board for it (it seem to be on the packaging label only). I think I will generate MAC based on host's unique board serial number (/sys/devices/virtual/dmi/id/board_serial) and PCI device identifier (i.e. in what slot it is in). Just wanted to make sure that there isn't a unique PHY ID that I can piggyback onto :)

Thanks a lot for your response!

—Vlad.

Altera_Forum · ‎02-17-2013

--- Quote Start ---

Thank you for your response! Yeah, not having a unique PHY ID is somewhat disappointing :) I am trying to avoid flashing the ID on the board because then I need to know a serial number of the board when programming it and I can't seem to find a way to query the board for it (it seem to be on the packaging label only). I think I will generate MAC based on host's unique board serial number (/sys/devices/virtual/dmi/id/board_serial) and PCI device identifier (i.e. in what slot it is in). Just wanted to make sure that there isn't a unique PHY ID that I can piggyback onto :)

--- Quote End ---

Where is the board serial number coming from? You'll have the same issue with that as a MAC, i.e., either can get erased.

In my designs, I use a serial EEPROM or MAX II UFM flash for the board serial number, manufacturing details etc. The MAC address is then constructed from the serial number.

Since this is a development board, you'll have to live within whatever constraints the original designers imposed on you. See if you can find out where they've stored the board serial number, and perhaps that'll give you an idea as to whether you should use it for the MAC, or store your MAC along with it.

Cheers,

Dave

Altera_Forum · ‎02-18-2013

If you have a source of random numbers use 46bits of randomness to generate a 'locally administered' MAC address.

(Or maybe just 24bits of randomness and 22bits of id).

Altera_Forum · ‎02-18-2013

--- Quote Start ---

Where is the board serial number coming from? You'll have the same issue with that as a MAC, i.e., either can get erased.

--- Quote End ---

The serial is coming from the motherboard of the host PC. You can get one through the DMI sub-system of the Linux kernel, for example:

# include <linux/dmi.h>
static int get_board_serial(u64 *dst)
{
    const char *s;
    s = dmi_get_system_info(DMI_BOARD_SERIAL);
    if (!s)
        return -1;
    if (kstrtou64(s, 10, dst))
        return -1;
    return 0;
}

This should make the unique, consistent MAC address (I don't like the idea of a random one!). I am also planning to provide a way to change it through ethtool.

Altera_Forum · ‎02-18-2013

Linux drivers tend to fall back on a random MAC address if they can't obtain the 'real' one, and then let ethtool be used to set it.

Using a property of the host's motherboard for a card's MAC address seems wrong to me, I'm not even sure that most x86 motherboards even has serial numbers - and trusting manufacturers to set them differently on every system is asking a lot.

Altera_Forum · ‎02-18-2013

Creating a MAC address from a serial number on the host PC is not a good idea. What happens when you plug in your second board? Or more likely, what happens when the next person working with your hardware decides to expand it to more boards?

You will only lead to much debugging pain!

Ideally, you would use the board to provide its own serial number.

However, here's a scheme where you could use the host to create a MAC address:

1. PCIe board boots and finds it has no MAC address, so it leaves its PHY in reset.

2. Host PC boots and loads the driver for your board.

3. The driver or application code accesses the board via PCIe to see if the board has initialized correctly.

4. If the board has no MAC, then the host creates and writes a MAC address to a register mapped to PCIe, and then instructs the board to enable the PHY.

In this scheme, the host can use the PCIe bus/slot/fun of the board along with the motherboard serial number to construct a unique MAC that is identical each time the system boots - allowing you to create a mapping in DHCP.

Cheers,

Dave

Altera_Forum · ‎02-18-2013

Dave,

The host's board serial is just a part of the MAC address. When you plug-in your second board, you plug it into another PCIe slot, which makes default MAC address different. When you expand it to more boards, the serial of the motherboard will be different. Of course, motherboard manufacturers may not provide a unique serial address. There are also CPU serial numbers, etc. It is just one of the way to make the default MAC address more or less unique. If it so happens that it is not unique, then you can easily change it with ethtool/ifconfig. That can be persisted in a simple configuration file or be a part of the networking script that sets up the interface. If I were to hard-code and not allow the MAC address to be changed, then I'd of course get concerned. Otherwise, I don't see using a mixture of DMI serials, PCIe bus/slot identification etc. a worse solution than accessing on-board flash memory. In fact, I think it is a lot better.

Altera_Forum · ‎02-18-2013

--- Quote Start ---

The host's board serial is just a part of the MAC address. When you plug-in your second board, you plug it into another PCIe slot, which makes default MAC address different. When you expand it to more boards, the serial of the motherboard will be different.

--- Quote End ---

Yep, I agree that this is an acceptable way to generate MAC addresses.

--- Quote Start ---

I don't see using a mixture of DMI serials, PCIe bus/slot identification etc. a worse solution than accessing on-board flash memory. In fact, I think it is a lot better.

--- Quote End ---

From a maintenance perspective, its nice to have unique serial numbers on boards that can be electronically accessed. For example, I have a system ~100 boards in CompactPCI crates, and in the next system I will have ~250 boards in CompactPCI Serial (PCIe) crates. The serial numbers on the boards are used to create the MAC addresses, which in turn are used by DHCP to get an IP, which in turn creates a unique hostname. I can log into any board in the system via its serial number.

Cheers,

Dave