[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Marc Leeman]

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 at 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

-- 
  greetz, marc
Human. It's kinda like Sebacean, but we haven't conquered other worlds
yet, so we just kick the crap out of each other.
	Crichton - PK Tech Girl
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080229/609583e9/attachment.pgp 

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Marc Leeman]

> 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?


-- 
  greetz, marc
Come on out, Chiana. Look, I don't have time to play this game. Durka's
gone Hannibal Lector on us.
	Crichton - Durka Returns
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080229/564a6a1a/attachment.pgp 

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Scott Wood]

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

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Marc Leeman]

> > 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 :)

-- 
  greetz, marc
Come on out, Chiana. Look, I don't have time to play this game. Durka's
gone Hannibal Lector on us.
	Crichton - Durka Returns
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080301/4a65f02d/attachment.pgp 

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Scott Wood]

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

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Jerry Van Baren]

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

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Marc Leeman]

> 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 at 24000 {
etc.



-- 
  greetz, marc
I'm only judging on my experience with you, but I've never seen such
a deficient species.
	Pilot - Crackers Don't Matter
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080301/9c7ef0c3/attachment.pgp 

[U-Boot-Users] 1.3.2-rc2 83xx CONFIG_HAS_ETHX not passing MAC addresses

[Jerry Van Baren]

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 at 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