[U-Boot] DM9000 issue in DM355
Ben,
I was taking a closer look at the DM9000 driver by trying it on the DM355 EVM. And it behaving a little different from before, i.e before we moved to the NET_MULTI stuff.
When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set.
So then I goto the U-Boot prompt and can clearly see that after giving the tftp command I have the ethaddr in my environment.
I do a saveenv and set a static ip and then can boot the kernel.
Even dhcp command does not work and times out.
Is there any CONFIG flag I am missing?
Just a couple months ago the DM9000 worked fine without any such issues.
Thanks, Sandeep
Paulraj, Sandeep wrote:
Ben,
Hi,
When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set.
Not sure, but it seems that the mac address is read from the eeprom connected to the DM9000 and it is not used again. I see that the mac address is copied into the environment variable, but is is not copied to the dev structure.
Could you give the following simple patch a try ?
Regards, Stefano
Stefano,
Paulraj, Sandeep wrote:
Ben,
Hi,
When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set.
Not sure, but it seems that the mac address is read from the eeprom connected to the DM9000 and it is not used again. I see that the mac address is copied into the environment variable, but is is not copied to the dev structure.
Could you give the following simple patch a try ?
Regards, Stefano
Thanks for your patch. I tried an image with your patch The issues still persists.
I am wondering if any other board using this driver is facing this issue. To me it seems to be generic to the DM9000.
It does not exist on the EMAC driver for DM355. dhcp works just fine.
Thanks, Sandeep
Stefano,
Paulraj, Sandeep wrote:
Ben,
Hi,
When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set.
Not sure, but it seems that the mac address is read from the eeprom connected to the DM9000 and it is not used again. I see that the mac address is copied into the environment variable, but is is not copied to the dev structure.
Could you give the following simple patch a try ?
Regards, Stefano
Thanks for your patch. I tried an image with your patch The issues still persists.
I am wondering if any other board using this driver is facing this issue. To me it seems to be generic to the DM9000.
It does not exist on the EMAC driver for DM355.
I meant EMAC driver for DM365. Obviously Dm355 does not have both DM9000 and EMAC :-)
dhcp works just fine. I meant on the DM365. dhcp does not work on DM355. It just times out.
Thanks, Sandeep
Hi Sandeep,
Paulraj, Sandeep wrote:
Ben,
I was taking a closer look at the DM9000 driver by trying it on the DM355 EVM. And it behaving a little different from before, i.e before we moved to the NET_MULTI stuff.
When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set.
So then I goto the U-Boot prompt and can clearly see that after giving the tftp command I have the ethaddr in my environment.
I do a saveenv and set a static ip and then can boot the kernel.
Even dhcp command does not work and times out.
Is there any CONFIG flag I am missing?
Just a couple months ago the DM9000 worked fine without any such issues.
Thanks, Sandeep
Sorry for taking so long to reply.
It looks like the DM9000 driver doesn't follow proper MAC address etiquette. The proper way is to read from NVRAM in the initialize() function and stuff it in dev->enetaddress. I'm separately sending a patch that compiles fine for me, but I don't have hardware. Please give it a shot, and if it's good we'll look at pulling it in.
regards, Ben
participants (3)
-
Ben Warren -
Paulraj, Sandeep -
Stefano Babic