Hi Alfred, alfred steele wrote: >> Thanks for your submission! >> > What is the current design on the mxc fec interface's attainment of a > MAC address. From the kernel driver it looks like it looks at the > IIM(IC identification registers) on the MXC platform(like mx51/35) to > look for a programmed mac address and then the set the fec mac to the > same . > > Looks like with the current mxc_fec driver there is not support for > the same. I am thinking of a mechanism to hardcode a fake MAC which > would subsequently be picked up by the kernel without using the > bd_info structure. > Any comments/suggestions? > > -Alfred. > I don't know much about this driver, but it appears to be doing things incorrectly. The correct flow is as follows. It is documented in 'doc/README.enetaddr':
1. The driver's initialize() function read from NVRAM if available. MAC address is stuffed into dev->enetaddr. The initialize() function should not try to get the address from the environment, which is where the imx27 driver goes wrong. 2. After all drivers have been initialized, eth_initialize() ( in net/eth.c) reads from the environment. If the value in the environment is valid and the value in dev->enetaddr is valid and both are different, the user is warned. The value in the environment overwrites the value in dev->enetaddr 3. When a network operation is performed, the driver's init() function is called, which is where the address is programmed into the device. As you can see, if the device is never used, step 3 is never exected and the device is never programmed. This is how it's supposed to work, since the U-boot design philosophy dictates that hardware is never touched unless it is used in U-boot. I'm pretty sure hard-coding a fake MAC address would run afoul of this rule. regards, Ben _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
