Hi Andy.
On Wed, Dec 7, 2011 at 11:24 PM, Andy Green andy.green@linaro.org wrote:
On 12/08/2011 02:36 AM, Somebody in the thread at some point said:
Just briefly commenting on the bits I have some experience with...
- Unless we use external USB/ETH adapters then cloning a master image
clones the mac address as well. This has serious consequences and I'm
This doesn't ring true. We do have different mac addresses, even on boards without flash and on-board ethernet.
How does it work? As far as I know mac address is burned in boot.scr, if you copy that (and tell me we don't) then we get duplicates.
Update: after a quick discussion on #linaro it seems that the mac address is actually burned into the hardware pack and lmc does not make one (at least not for panda). I have not verified this yet but if true then _all_ pandas with a given hwpack build get the same mac.
If you're running TI LT kernels for Panda, and it has also been true for linux-linaro- on Panda, then I added patches a while back to munge a MAC address from the CPU's allegedly-GUID ID number. That is consistent for a particular Panda board, and there's at least a selection of possible MAC addresses to reduce chance of collision. It's unclear how wide that selection is but it isn't tiny.
I see, that would make some sense (sadly not as much as putting a 1K NV storage on a panda by TI). I need to check how my boot.scr got a hard-wired mac address in its boot.src because I'm 100% sure that I did not touch it though.
corrupted) before booting to ensure consistent behaviour. I did some work on that and I managed to boot panda over NFS. Ideally I want to boot over nbd (netblock device) which is much faster and with proper "master image" init script we can expose a single read only net block device to _all_ the boards.
FWIW I used NBD some years ago and it worked great. You have to take care about building some userland footprint for it but otherwise I found it much more effective and reliable than NFS.
Edubuntu uses NBD and I talked with the person that implemented that part. It seems very fast and reliable and with single readonly rootfs image they export it seems to be just perfect for what we wanted.
- Start with what we have but make it 100% automatic. Fix MAC issues.
If you're faced with a board that has no on-PCB NV storage for this kind of identity information, if the CPU has a GUID then I can recommend forming the MAC from it.
Right now I would use a explicitly set mac that lava also knows about. It's something you would generate on the server. Then plaster a file on the SD card. The boot script would load that file and set the mac address accordingly.
This only applies to boards with no NV storage and on-board ETH. For beagle C4 and origen we can depend on non-crappy USB/ETH adapters.
Doing stuff like that based on the board id sounds nice but has some drawbacks:
1) It does not work in all cases (older kernels, older bootloaders maybe) 2) It requires some per board magic which might take a time to happen in all the kernel trees (unless it is already done) 3) Lava does not know it. We can do smarter things when we know the mac of each board we have (like allow it to tftp boot + nbd boot later). We can also do tests on static IP addresses if we want to as we can control dhcp.
Thanks for your feedback! ZK