On 03/25/2011 11:49 AM, Somebody in the thread at some point said:

On Thursday 24 March 2011, Andy Green wrote:

quoted

Introduce a generic helper function that can set a MAC address using
data from the OMAP unique CPU ID register.

For comparison purposes this produces a MAC address of

   2e:40:70:f0:12:06

for the ethernet device on my Panda.


Note that this patch requires the fix patch for CPU ID register
indexes previously posted to linux-omap, otherwise the CPU ID is
misread on Panda by the existing function to do it.  This patch
is already on linux-omap.

"OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430"
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9

Signed-off-by: Andy Green<redacted>

Acked-by: Arnd Bergmann<arnd@arndb.de>

Thanks.

TI folks: While this is a working solution, I still think it would
be good to get an officially sanctioned method that allows the creation
of a IEEE 802 MAC address in a range assigned to TI instead of using
an address from the locally administered range.

Is that something that can be done?

Having a proper MAC from IEEE assigned for each interface is of course 
ideal.

But even if that happened today though, on Panda there is no "board 
identity storage" to put the reserved MAC addresses in to bind it to the 
physical board.  If you try to manage them on SD Card, you have the 
problem of dealing with correct MAC addresses needing putting there 
again every time it is nuked.  So it doesn't in itself help in the Panda 
case.

David Anders mentioned yesterday that for next OMAP board, he probably 
puts a general board identity EEPROM where one could stash MACs.  This 
kind of API can be extended to query the EEPROM at device-register-time 
and fetch the MAC instead of compute it.  So I think we go in a 
reasonable direction even when it is possible to get assigned MACs.

-Andy