[U-Boot-Users] Passing MACs to Linux

[U-Boot-Users] Passing MACs to Linux

[Russell McGuire]

Guys, 

 

I am sure this has been brought up a number of times, so forgive me in
advance.

I did notice however, not sure which version, but between 1.3.1 and 1.3.3
U-boot 

That my MAC for my Ethernet device was no longer being passed into linux, or
perhaps over written by the blob.

 

So for a quick status check.

 

What is the current operation / priority of how MACs are passed into Linux
2.6.24+ vs the U-boot 1.3.3+ environment string?

 

Russell McGuire

Senior Systems Engineer

rmcguire at videopresence.com

503.888.0968

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080605/f9c01f0a/attachment.htm 

[U-Boot-Users] Passing MACs to Linux

[Wolfgang Denk]

In message <E6746F4E58F84F74A00907F0ECE81BE8@absolutdaddy> you wrote:
> 
> I am sure this has been brought up a number of times, so forgive me in
> advance.

No. We do not forgive ignorance nor intentional ignoring established
netiquette which for example requires you to actually search the
archives and to read the FAQ before posting.

> I did notice however, not sure which version, but between 1.3.1 and 1.3.3
> U-boot 

Well, please find out which specific version (git commit ID) caused
any changes...

> That my MAC for my Ethernet device was no longer being passed into linux, or
> perhaps over written by the blob.

I see. And now you expect us to guess which processor architecture
this is, and what board, and you don't even give us a version? 

You expect too much.

> What is the current operation / priority of how MACs are passed into Linux
> 2.6.24+ vs the U-boot 1.3.3+ environment string?

It dpeneds on a lot of things, including processor architecture in
U-Boot, processor architecture in Linux, etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Love your country but never trust its government."
- from a hand-painted road sign in central Pennsylvania

[U-Boot-Users] Passing MACs to Linux

[Jerry Van Baren]

Russell McGuire wrote:
> Guys,
> 
> I am sure this has been brought up a number of times, so forgive me in 
> advance.
> 
> I did notice however, not sure which version, but between 1.3.1 and 
> 1.3.3 U-boot That my MAC for my Ethernet device was no longer being
> passed into linux, or perhaps over written by the blob.
> 
> So for a quick status check.
> 
> What is the current operation / priority of how MACs are passed into 
> Linux 2.6.24+ vs the U-boot 1.3.3+ environment string?

Check what your .dts source looks like vs. an example .dts of the same 
processor (and, preferably a similar/same board) from the linux source 
tree.  As you noticed, things have been improving in the 2.6.2x and 
1.3.x timeframes, but .dts improvements are necessary to support the 
code improvements.

I would especially look at your .dts and see if it has a /aliases node 
with properties that point to your CPU, serial, ethernet, (and other?) 
properties.  The newer fixup functions look up the generic name in 
/aliases and use that to find the "real" property to fix up rather than 
having lots of hardcoded board/cpu specific #defines compiled into 
u-boot to fix up the "real" property directly.

"All problems in computer science can be solved by another level of 
indirection." - Butler Lampson

HTH,
gvb

[U-Boot-Users] Passing MACs to Linux

[Russell McGuire]

To save most the banter, and rephrasing:

What is the 'EXPECTED' current behavior of the 83xx/6xx architecture for the
most current 1.3.3+ GIT release of passing MACs into Linux 2.6.24. Lastly, I
am using the UEC 83xx driver.

I have defined QE_OF.
I have defined CONFIG_UEC_ETH. 
I have defined CONFIG_ETHADDR.

My 8360.blob/dts does have MAC address definitions, but are set to ZERO's.
<See below> In previous releases this was over written by U-boot, thus using
the CONFIG_ETHADDR address to be used within Linux 2.6.24.

Most recently <since 1.3.1>, I now have to add valid MACs to the
8360.blob/dts file to get a MAC to be set within Linux. Does U-boot no
longer over write if a blob already has any MAC set? I don't care what used
to work really, I just would like to know what the current method is.

Here is my current dts entry of note, previously <1.3.1> I didn't have to
set 'mac-address' / could leave it at all-zeros. Now, I do have to set
mac-address. Again, not worried about any previous method working, just
looking for current method that is correct.

ucc at 2000 {   //UCC1
	device_type = "network";
	compatible = "ucc_geth";
	model = "UCC";
	device-id = <1>; // UCC1
	reg = <2000 200>;
	interrupts = <20>;
	interrupt-parent = < &qeic >;
	/*
	 * mac-address is deprecated and will be removed
	 * in 2.6.25.  Only recent versions of
	 * U-Boot support local-mac-address, however.
	 */
	mac-address = [ 00 04 9f ef 01 01 ]; 
	local-mac-address = [ 00 00 00 00 00 00 ]; 
	rx-clock = <0>;
	tx-clock = <19>;
	phy-handle = <212000>;
	pio-handle = < &pio1 >;
	phy-connection-type = "rgmii-id";
};

-Russ

History Below Probably not worth reading.

>No. We do not forgive ignorance nor intentional ignoring established
>netiquette which for example requires you to actually search the
>archives and to read the FAQ before posting.

I did, and thanks, not mentioned, not up-to-date, or unclear, or broken, or
deprecation has been reversed. 

>Well, please find out which specific version (git commit ID) caused
>any changes...

Be great, however, my question didn't ask where it broke, just what current
behavior was, admittedly hard to answer without known architecture. Most of
us don't have time to check several hundreds commit IDs. Besides it doesn't
seem broke, perhaps this is planned obsolescence, hence my question.
Experience with U-boot has taught me that 80% is user misuse, or not-getting
coordinated documentation from all the different pieces that play together.

>I see. And now you expect us to guess which processor architecture
>this is, and what board, and you don't even give us a version? 

Yes, I expect full cooperation of the psychic-network, did you get the Memo?
Besides surely you are a good enough hacker to have access by now, and have
answered your own question. Perhaps we can write a quick application that
back searches the list, and throws this into a HEAT style database, with
last posted messages, so it can pull my architecture automatically? I'll
spiff that up for you, should be on your desk by Monday.

Seriously enjoy the humor, apologies for forgetting. Normally I put all that
in the subject line to save you from even having to open the post.

[U-Boot-Users] Passing MACs to Linux

[Jerry Van Baren]

Russell McGuire wrote:
> To save most the banter, and rephrasing:
> 
> What is the 'EXPECTED' current behavior of the 83xx/6xx architecture for the
> most current 1.3.3+ GIT release of passing MACs into Linux 2.6.24. Lastly, I
> am using the UEC 83xx driver.
> 
> I have defined QE_OF.
> I have defined CONFIG_UEC_ETH. 
> I have defined CONFIG_ETHADDR.
> 
> My 8360.blob/dts does have MAC address definitions, but are set to ZERO's.
> <See below> In previous releases this was over written by U-boot, thus using
> the CONFIG_ETHADDR address to be used within Linux 2.6.24.
> 
> Most recently <since 1.3.1>, I now have to add valid MACs to the
> 8360.blob/dts file to get a MAC to be set within Linux. Does U-boot no
> longer over write if a blob already has any MAC set? I don't care what used
> to work really, I just would like to know what the current method is.
> 
> Here is my current dts entry of note, previously <1.3.1> I didn't have to
> set 'mac-address' / could leave it at all-zeros. Now, I do have to set
> mac-address. Again, not worried about any previous method working, just
> looking for current method that is correct.

/aliases/ethernet0 = ???

Use "fdt print /", "fdt print /aliases", "fdt chosen", and "fdt bd"(?) 
at the u-boot command line to see what your blob looks like and how 
creating the /chosen node and board fixups change it.

References:
common/fdt_support.c (ethernet fixup for mac address, dereferences the 
/aliases node)
<http://git.denx.de/?p=u-boot.git;a=blob;f=common/fdt_support.c;h=75077442d85dbc2fc38ae02e80be1c5485b391c9;hb=HEAD#l379>

> ucc at 2000 {   //UCC1
> 	device_type = "network";
> 	compatible = "ucc_geth";
> 	model = "UCC";
> 	device-id = <1>; // UCC1
> 	reg = <2000 200>;
> 	interrupts = <20>;
> 	interrupt-parent = < &qeic >;
> 	/*
> 	 * mac-address is deprecated and will be removed
> 	 * in 2.6.25.  Only recent versions of
> 	 * U-Boot support local-mac-address, however.
> 	 */
> 	mac-address = [ 00 04 9f ef 01 01 ]; 
> 	local-mac-address = [ 00 00 00 00 00 00 ]; 
> 	rx-clock = <0>;
> 	tx-clock = <19>;
> 	phy-handle = <212000>;
> 	pio-handle = < &pio1 >;
> 	phy-connection-type = "rgmii-id";
> };
> 
> -Russ

Best regards,
gvb

[U-Boot-Users] Passing MACs to Linux

[Paul Gortmaker]

[I know this is old, but it may save someone else some pain...]

On Thu, Jun 5, 2008 at 11:59 AM, Russell McGuire
<rmcguire@videopresence.com> wrote:
> To save most the banter, and rephrasing:
>
> What is the 'EXPECTED' current behavior of the 83xx/6xx architecture for the
> most current 1.3.3+ GIT release of passing MACs into Linux 2.6.24. Lastly, I
> am using the UEC 83xx driver.
>
> I have defined QE_OF.
> I have defined CONFIG_UEC_ETH.
> I have defined CONFIG_ETHADDR.

I'm betting you didn't have CONFIG_HAS_ETH0 though.

>
> My 8360.blob/dts does have MAC address definitions, but are set to ZERO's.
> <See below> In previous releases this was over written by U-boot, thus using
> the CONFIG_ETHADDR address to be used within Linux 2.6.24.
>
> Most recently <since 1.3.1>, I now have to add valid MACs to the
> 8360.blob/dts file to get a MAC to be set within Linux. Does U-boot no
> longer over write if a blob already has any MAC set? I don't care what used
> to work really, I just would like to know what the current method is.

The overwrite code is in common/fdt_support.c -- and it only takes
place for devices which you define CONFIG_HAS_ETHn  (n=0,1,2...)
If you don't define this, then your zeros in the dts/dtb live on, and get
passed into the kernel as-is.   I just tripped over this myself recently.

Paul.

>
> Here is my current dts entry of note, previously <1.3.1> I didn't have to
> set 'mac-address' / could leave it at all-zeros. Now, I do have to set
> mac-address. Again, not worried about any previous method working, just
> looking for current method that is correct.
>
> ucc at 2000 {   //UCC1
>        device_type = "network";
>        compatible = "ucc_geth";
>        model = "UCC";
>        device-id = <1>; // UCC1
>        reg = <2000 200>;
>        interrupts = <20>;
>        interrupt-parent = < &qeic >;
>        /*
>         * mac-address is deprecated and will be removed
>         * in 2.6.25.  Only recent versions of
>         * U-Boot support local-mac-address, however.
>         */
>        mac-address = [ 00 04 9f ef 01 01 ];
>        local-mac-address = [ 00 00 00 00 00 00 ];
>        rx-clock = <0>;
>        tx-clock = <19>;
>        phy-handle = <212000>;
>        pio-handle = < &pio1 >;
>        phy-connection-type = "rgmii-id";
> };
>
> -Russ
>