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

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