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