OMAP L-137 TI Ethernet driver

We have considered doing this in u-boot also, but I think it will eventually be stored in write-once memory during manufacture. You might consider that option too. (I'm not suggesting that I've done it or know how to do it, but if you have to develop a Linux driver, you might as well do it the way you need to do it in the long run...)

I don't have a lot of choice since the board will not be equipped with an EEPROM. I'm not willing to develop my own driver since the TI EMAC driver should be sufficent for me apart from the fact that it now gets it's MAC address via i2c.

• What is the reason you think I should consider storing the MAC address in write-once memory? The environment variables of U-Boot are programmed automated during the production of the device and the serial port is not accessible for the outside world. Adding the EEPROM would only result in an extra component on the board.

I noticed that when the Kernel starts up the following lines pass the console:

Uncompressing Linux.............................................................
....................... done, booting the kernel.
....
RAMDISK driver initialized: 1 RAM disks of 16384K size 1024 blocksize
netconsole: not configured, aborting
Davinci EMAC MII Bus: probed
DaVinci EMAC: Unable to read MAC from EEPROM, no I2C support in kernel.
MAC address is deadbeaf
TI DaVinci EMAC Linux version updated 4.0
Creating 3 MTD partitions on "Windbond spi nand flash":
0x00000000-0x00020000 : "U-Boot"
0x00020000-0x00024000 : "U-Boot Environment"
0x00024000-0x00400000 : "Linux"
dm_spi.0: davinci SPI Controller driver at 0xc185c000 (irq = 20) use_dma=1
dm_spi.1: davinci SPI Controller driver at 0xc185e000 (irq = 56) use_dma=1
....
MontaVista(R) Linux(R) Professional Edition 5.0.0 (0801921)

• As you can see the MAC address is programmed before the U-Boot partitions are created. So it might be a problem to read the U-Boot variables before the partition is created, or does anyone know how to work around this problem? Can I for example change the order of execution in this sequence?
• The /drivers/net/davinci_emac.c contains a static int emac_dev_init(struct net_device *netdev) this function tries to obtain the MAC address by calling davince_get_macaddr(). So adding a custom function mydev_get_macaddr() which reads the info from /dev/mtdblock1 should be the correct way of doing this or not?

The file /arch/arm/plat-davinci/i2c-emac.c contains two functions;
****************************************************************************************************
/* Get Ethernet address from kernel boot params */
static unsigned char cpmac_eth_string[20] = "deadbeaf";

/*
 * This function gets the Ethernet MAC address from EEPROM
 * input buffer to be of at least 20 bytes in length.
 */
int davinci_get_macaddr(int adap_num, char *ptr)
{
#ifndef CONFIG_I2C_DAVINCI
    printk(KERN_INFO "DaVinci EMAC: Unable to read MAC from EEPROM, "
           "no I2C support in kernel.\n");
#else
   // Not important since i2c is disabled
#endif
    {
        strcpy(ptr, cpmac_eth_string);
    }
    return 0;
}
EXPORT_SYMBOL(davinci_get_macaddr);

static int davinci_cpmac_eth_setup(char *str)
{
    /* The first char passed from the bootloader is '=', so ignore it */
    strcpy(cpmac_eth_string, str + 1);

    printk("TI DaVinci EMAC: Kernel Boot params Eth address: %s\n",
        cpmac_eth_string);

    return 1;
}
__setup("eth", davinci_cpmac_eth_setup);
****************************************************************************************************

• I don't understand what this second function static int davinci_cpmac_eth_setup(char *str) does. Enables this function the ability the pass a MAC address as a Kernel boot parameter in U-Boot i.e. console=ttyS2,115200n8 noinitrd ... mem=16M eth=de:ad:00:00:be:ef?

• After the board is booted I can run ifconfig eth0 hw ether de:ad:00:00:be:ef and that successfully updates the MAC address. But I would be a lot nicer to perform this in the Kernel bootup.

Could anyone help me answer these questions?

Thanks in advance

LUKLEM said:

What is the reason you think I should consider storing the MAC address in write-once memory? The environment variables of U-Boot are programmed automated during the production of the device and the serial port is not accessible for the outside world. Adding the EEPROM would only result in an extra component on the board.

The write-once memory I'm talking about is on-chip memory. It is not a separate EEPROM. If you have an OMAP-L137, you have the memory on the chip. As long as the environment variables are programmed during manufacture, I think you could do that too. Either way would work.

LUKLEM said:

• As you can see the MAC address is programmed before the U-Boot partitions are created. So it might be a problem to read the U-Boot variables before the partition is created, or does anyone know how to work around this problem? Can I for example change the order of execution in this sequence?

The "Uncompressing LInux" message you see is the result of u-boot performing a boot command, so u-boot is already running. The u-boot partition information you see displayed is just "informing Linux" of those partitions. U-boot has already run.

Any way that successfully identifies your unique MAC address for Linux is the "correct way".