Subject: [RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

From: [email-masked] (Andy Green)
Date: Fri, 25 Mar 2011 13:34:04 +0000

On 03/25/2011 01:24 PM, Somebody in the thread at some point said:
> On Friday 25 March 2011, Andy Green wrote:
>> 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.
>
> What I meant is computing an official MAC address from the same input
> data as you already do. Unfortunately that would mean having at most 24
> bits available instead of the 44 or so bits you currently use, because
> the upper half of the address then becomes fixed.
>
> Also it would require
> 1. defining an new algorithm that computes the lower 24 bits from the
>     die ID in a way that minimises the chances of collision
> 2. Getting an official identifier for the upper half of the address
>     assigned to the OMAP3/OMAP4 CPUs
> 3. Documenting this method in the OMAP data sheets.

I see.  It would work OK then.  They probably wouldn't want to blow 
their $1750 just on Panda though, so maybe they set 4 bits or whatever 
and let 20 be computed.

However, the only practical advantage is that it would show up as a TI 
MAC in an OUI database.  The "locally administered" address as used at 
the moment is otherwise legal in every respect AFAIK.

-Andy