[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses
When booting an 8347 processor, the MAC addresses (ethaddr and eth1addr) don't seem to get passed anymore.
I modified my config to include CONFIG_HAS_ETH0 and CONFIG_HAS_ETH1 and I am entering the code in fdt_fixup_ethernet (common/fdt_support.c) but get stuck at node = fdt_path_offset(fdt, "/aliases");
Once this fails, the MAC addresses are not passed along.
Any search on [mleeman@neo linux-2.6.24]$ grep aliases arch/powerpc/boot/dts|wc -l 0
turns up empty for the 2.6.24 kernels, looking for "aliases" in the kernel Documentation does not give a hit that seems relevant for device trees.
and the only ref that seems to be on topic is: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/36004
Is this using some dts node that is not yet in the released kernel (2.6.24) [1]?
[1] It's probably something I missed since I found this one too: http://patchwork.ozlabs.org/linuxppc/patch?id=12671
turns up empty for the 2.6.24 kernels, looking for "aliases" in the kernel Documentation does not give a hit that seems relevant for device trees.
and the only ref that seems to be on topic is: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/36004
Looks like something that was introduced between 2.6.24 and 2.6.25-rc3; does this mean that u-boot-1.3.2 will not be able to boot 834x processors (networking that is) with kernels before 2.6.25?
On Fri, Feb 29, 2008 at 02:49:08PM +0100, Marc Leeman wrote:
turns up empty for the 2.6.24 kernels, looking for "aliases" in the kernel Documentation does not give a hit that seems relevant for device trees.
and the only ref that seems to be on topic is: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/36004
Looks like something that was introduced between 2.6.24 and 2.6.25-rc3; does this mean that u-boot-1.3.2 will not be able to boot 834x processors (networking that is) with kernels before 2.6.25?
No, it just means you need the newer device tree.
-Scott
Looks like something that was introduced between 2.6.24 and 2.6.25-rc3; does this mean that u-boot-1.3.2 will not be able to boot 834x processors (networking that is) with kernels before 2.6.25?
No, it just means you need the newer device tree.
Of course, but since the device tree is part of the kernel, this would mean that it's no longer possible to boot from an unmodified released kernel with 1.3.2.
Unless 2.6.25 is released before 1.3.2 :)
On Sat, Mar 01, 2008 at 12:06:14PM +0100, Marc Leeman wrote:
Looks like something that was introduced between 2.6.24 and 2.6.25-rc3; does this mean that u-boot-1.3.2 will not be able to boot 834x processors (networking that is) with kernels before 2.6.25?
No, it just means you need the newer device tree.
Of course, but since the device tree is part of the kernel,
It's not part of it; it just happens to be distributed with the kernel.
There's no reason why u-boot couldn't have its own repository of device trees.
-Scott
Marc Leeman wrote:
When booting an 8347 processor, the MAC addresses (ethaddr and eth1addr) don't seem to get passed anymore.
I modified my config to include CONFIG_HAS_ETH0 and CONFIG_HAS_ETH1 and I am entering the code in fdt_fixup_ethernet (common/fdt_support.c) but get stuck at node = fdt_path_offset(fdt, "/aliases");
Once this fails, the MAC addresses are not passed along.
Disclaimer: I have not researched this...
I presume the problem is that the /aliases node doesn't exist in your tree (original kernel .dts source, and thus the .dtb blob). One simple solution would be to create the /aliases node if it doesn't exist, just like we create the /chosen node if it doesn't exist.
Best regards, gvb
I presume the problem is that the /aliases node doesn't exist in your tree (original kernel .dts source, and thus the .dtb blob). One simple solution would be to create the /aliases node if it doesn't exist, just like we create the /chosen node if it doesn't exist.
Yep, that's how I got to boot my kernel again, forgot to post this in my previous mail:
aliases { ethernet0 = &enet0; ethernet1 = &enet1; serial0 = &serial0; serial1 = &serial1; pci0 = &pci0; };
And then adding the correct aliases of course: enet0: ethernet@24000 { etc.
Marc Leeman wrote:
I presume the problem is that the /aliases node doesn't exist in your tree (original kernel .dts source, and thus the .dtb blob). One simple solution would be to create the /aliases node if it doesn't exist, just like we create the /chosen node if it doesn't exist.
Yep, that's how I got to boot my kernel again, forgot to post this in my previous mail:
aliases { ethernet0 = &enet0; ethernet1 = &enet1; serial0 = &serial0; serial1 = &serial1; pci0 = &pci0; };
And then adding the correct aliases of course: enet0: ethernet@24000 { etc.
Ahh, right. My thought of auto-creating the /aliases node is a very bad idea. We could guess that ethernet0 is suppose to be mapped to &enet0, but it would be a guess and there is a non-trivial probability of guessing wrong. The whole *reason* for having an /aliases node is to avoid guessing (and being wrong sometimes). The /aliases node really is describing how the board is to be used, so it really needs to be defined in the .dts source.
Best regards, gvb
participants (3)
-
Jerry Van Baren -
Marc Leeman -
Scott Wood