AM3517 MAC addresses

It looks like the MAC values for the 8 channels are done by sequential writes to the MACINDEX and MACADDRLO registers, where you set the channel you are about to set the MAC address of in the MACINDEX register, than set the value for the lowest byte of the MAC address in MACADDRLO. It seems that the 8 channels also do not have totally unique addresses, only the lowest byte of the MAC address will differ between the 8 channels, which is why you can change the MAC addresses without touching MACADDRHI once it is set after the first MAC address configuration for the first channel.

This process is mentioned briefly in section 22.2.9.3 of the TRM. In general this is a process that should be handled by the OSes Ethernet driver, so a normal user should not have to mess with it unless they are writing their own Ethernet driver for another OS, in which case it would probably be a good idea to start with the Linux driver's source as an example.

What is the purpose of the registers CONTROL_FUSE_EMAC_LSB & CONTROL_FUSE_EMAC_MSB?

These are in the AM3517 TRM but there are no details.

Thx,

Mark

mutter said:

What is the purpose of the registers CONTROL_FUSE_EMAC_LSB & CONTROL_FUSE_EMAC_MSB?

These registers are read when booting via Ethernet.  This determines the source MAC address set in the boot announce frame and ACK frames from the device.  Refer to the EMAC boot section, 24.4.5.4, of the TRM for more details. 

Dave,

Thx.

Are these register contents unique for each AM3517 device?

-Mark

Mark,

I believe the contents should be unique.  The MSB will be identical (00.24.BA, corresponding to TI), and a unique LSB for each device.  At least, I checked 3 different SOMs and they all had unique MAC addresses.

David,

I can't see the MAC addresses you (MSB 00.24.BA) on my AM3517 EVMs. Where is this read and configured? In U-boot, kernel, or ??? Any special setup needed?

I currently use PSP 3.00.00.04.

Right now I get some random MAC addresses from Linux if I don't use the eth=aa:bb:cc:ee:dd:ff kernel arg. However I don't know the full MAC address of my module... The sticker on the SOM apparently has the MAC for the WLAN module only (at least that is what the LogicPD site says and it starts with 00:08:EE in all cases).

So far I didn't care but now I am using software that needs the mac address and I don't want to recompile for every time I boot Linux.

Regards.

Frank,

The MAC address I referred to is located in the CONTROL_FUSE_EMAC_LSB and CONTROL_FUSE_EMAC_MSB registers (addresses 0x4800 2380 and 0x4800 2384, respectively).  Nothing needs to be done on your part to configure this.  I'm not aware of any application that uses these values other than the ROM code for EMAC boot, but they are readable if you need to obtain a unique MAC address.  Of course, the address found on the sticker on the SOM is also a unique MAC address.

The fist 3 values in the MAC address are typically reserved for a specific company.  For example, the 00:24:BA:xx:xx:xx addresses are reserved for TI and 00:08:EE:xx:xx:xx addresses are reserved for LogicPd.

I hope that answers your questions.  Let me know if you need more clarification.

I think that is the problem:

David Meixner said:

I'm not aware of any application that uses these values other than the ROM code for EMAC boot

I was expecting the PSP to be smart enough and assign the MAC value based on the hardware. If I use the sticker address I will have a conflict later if I start to use the WLAN... Same for customers.

And I would prefer the correct TI MAC address. I will see if am able to implement a patch in the EVMs board files. Otherwise I will have to do a PSP feature request.

Thanks.

I would like to add to this thread and concur with Frank's concerns.

In my particular case, I was going through the "out-of-box" experience that our customer's would since I had not done this with the AM3517 EVM specifically.  The EVM came with u-boot, the linux kernel and filesystem all in the on board flash so therefore, it powered up and ran the cube demo.  (That is the good news).

The bad news is that I then endeavored to build the kernel and mount an NFS filesystem.  We typically do when trying to put together a different demo or want to excersize a different interface (eg. CAN).  I spent quite a bit of time questioning my skills regarding the tftp server setup, even though I knew unequivocally that I had it setup correctly, to find out by searching Goolge for "AM3517 u-boot" that this thread  and another one on E2E were discussing that u-boot's ethaddr environment variable was not set.  Since I did not want to spend more time trying to figure out my specific die's MAC address, I used the LogicPD one on the sticker in the interim.

The morale to this story, if the customer  had received this EVM initially, it would have resulted in a phone call and a frustrating experience for both of us.

1) At a minimum, the EVM needs to have u-boot's ethaddr set appropriately.

2) The AM3517 u-boot needs to be fixed to address this lower case/upper case thing with the MAC address.

BrandonAzbell said:

1) At a minimum, the EVM needs to have u-boot's ethaddr set appropriately.

I will look into submitting a feature request to have this in the next PSP release.

BrandonAzbell said:

2) The AM3517 u-boot needs to be fixed to address this lower case/upper case thing with the MAC address.

I've been successful in setting the MAC address using both lower and upper case letters.  Perhaps this has been fixed in newer u-boot versions.  I am using 2009.08.

All,

The MAC address needs to be programmed indepedently in U-boot and Kernel respectively. There was an initial proposal to have this programmed on I2C EEPROM. The protocol to read values from this EEPROM was not something the Community Kernel(custom) supported.  Hence we followed an approach to manually set the "ethaddr" U-boot environment variable once for the board and pass it through bootargs to the kernel. This was also necessary as the initial Si didnt have the MAC address programmed in the EFUSE. I will review the same with the HW APPs team and once confirmed we can make suitable modifications to both U-boot and kernel to fetch this from the EFUSE directly(and not rely on passing MAC address through bootargs)

With regard to using multiple MAC addresses(upto 8 addresses, one for  each DMA channel), this feature will be required only when you want to create logical interfaces for segregating traffic flows. I have come across this requirement only in the context of multi-core systems where different cores can handle individual logical channels separately. Currently, none of this is supported in the Linux EMAC driver implementation ( we use 1 MAC address and 1 Tx/Rx DMA channels)

Regards

Sriram

Srirama,

Any status on a patch for this?  We are starting to see customers with bulk orders and none of them want to manually adjust the U-Boot environment to pass a parameter to the Linux kernel.

Regards,

--mike

Mike

I can share an initial patch by friday that should address this on AM3517- the patch will be made available in the staging repo soon after

Regards

Sriram

Srirama,

That is great news.  I appreciate the quick response.

Best regards,

--mike

Mike,

i have pushed the patch that reads the MAC address from E-fuse to the U-boot staging area : http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary

You can pick the specific commit: http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=commit;h=eba4646983241473dab4fbcc2571a607f0da9090

With this scheme, the uboot init code will look for whether the "ethaddr"  environment variable is set - this is provided as an override option.

If the variable is not, then it queries for the same from E-fuse registers in control register space. If it finds a valid address there, it will set the "ethaddr" variable and program the same in HW.

To use the MAC ID from E-fuse, do the following:

One-time operation:

1) setenv ethaddr     

2)saveenv

This is will erase the currently saved address in environment variable

Reboot

1) Uboot init code will detect the MAC address automatically and set ethaddr for you

2) ethernet address will be passed to kernel through "eth=" argument based on the ethaddr environment variable  (this method is deprecated , but is needed for boards which do not have the efuse addresses, auto-generating random MAC address seems to exhaust the Address pool of the DHCP server soon)

Will also add a similar patch in kernel, but the current scheme of passing the address through "eth=" bootargs should work

Regards

Sriram

Hi David,

David Meixner said:

I believe the contents should be unique.  The MSB will be identical (00.24.BA, corresponding to TI), and a unique LSB for each device.  At least, I checked 3 different SOMs and they all had unique MAC addresses.

Is it guaranted that the MAC address fused on an AM3517 device will  be unique? Or can it happen that addresses that have been already e-fused might be re-used over time on newer AM3517?

Thanks in advance and best regards,

Anthony

Since this MAC address is unique and belongs to TI, if we are using AM35x for mass production, can I use this address as the MAC address of our product?   If I cannot use it, where should I save the MAC address to make it persistent?