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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
