On 7/14/07, Wolfgang Denk wd@denx.de wrote:
In message 1defaf580707121538y65db81c9y748f14b9a62ea31b@mail.gmail.com you wrote:
When I submitted the macb ethernet driver, which works on both avr32 and at91sam926x devices, for inclusion in the LInux kernel, I was told to remove the mac address from the platform data. This was because ARM
So far this is most probably correct.
relied on u-boot initializing the mac address of all ethernet controllers before booting Linux, so AVR32 should do the same as well.
This is definitely not correct. U-Boot's position about this is very clear, and has been for a long time. This is actually a FAQ, please look it up.
Well, the mac address must be passed _somewhere_, so they are either both correct or both incorrect. But after reading the FAQ and the linux-arm thread it links to, it's clear to me that AVR32 is right and ARM is wrong, i.e. passing the mac address through the boot protocol (ATAGs or otherwise) is the right thing to do.
So I will just forget about "fixing" u-boot and instead consider posting a patch for the macb driver to look for the mac address in the platform_data instead of the hardware registers. I don't have the time to start a flamewar right now, so it'll have to wait until after my vacation at least.
I'd be happy to go back to passing mac addresses through the tagged list (in fact, u-boot never stopped doing that on avr32) but this needs to be resolved on ARM before I can change the driver.
The thing is that the ARM folks don't want o see MAC addresses in ATAGs either. Don't ask me why - if they use this mechanism for passing h/w related information around that would seem the most logical approach to me, too. But they don't want it.
Yeah, I got the impression that they wanted to break nfsroot just for the heck of it...
<asbestos> The Right Thing (TM) would of course be to get rid of all this ATAGs stuff on ARM and use a proper device tree there, too, like the PowerPC folks have been doing for such a long time. And on MIPS and all the other systems, too. </asbestos>
Heh. AVR32 uses ATAGs too, so I suppose you want me to switch as well?
I guess I should look into it. Switching boot protocol sounds like a long and painful experience though...
[He, I'm leaving for vacation, so I won't suffer from the fires of the flame war I just started :-) ]
People don't seem to be taking the bait so far ;-)
Håvard