[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.