On this thought.... On Wed, Dec 7, 2011 at 7:54 PM, Ricardo Salveti <ricardo.salv...@linaro.org> wrote: > On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki > <zygmunt.kryni...@linaro.org> wrote: >> W dniu 07.12.2011 18:44, Paul Larson pisze: >>> >>> On Wed, Dec 7, 2011 at 10:01 AM, Zygmunt Krynicki >>> <zygmunt.kryni...@linaro.org <mailto:zygmunt.kryni...@linaro.org>> wrote: >>> >>> Hi, sorry for the topic, I wanted to catch your attention. >>> >>> This is a quick brain dump based on my own observations/battle with >>> master images last week. >>> >>> 1) 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. > > As I said at #linaro, there's no default mac address at any hwpack we > produce. If you have a boot.scr with a mac address pre-defined, then > you either customized your own hwpack or it's a bug.
There is a proposed new option to linaro-media-create to allow you to customize your install. Basically it allows for scripts to be run as part of the linaro-media-create process. Want an update boot.scr or whatever, go nuts, it'll allow for it. This was something alf, mabac and I had spec'd it out at the last LC. > I believe we already have a valid and unique mac address for all the > boards we currently support, even if they rely on being calculated > during boot time (like the hack that Andy did for panda). Let me know > if you're still having issues with random mac address every time you > boot your board. > >>> The process isn't *that* >>> hard. It's essentially just a nano image, a couple of extra packages >>> installed, and add a few partitions. However, I do agree with the >>> sentiment that this should be automated as much as possible. >>> >>> 2) Running code via serial on the master image is a mess. It is very >>> fragile. We need an agent on the board instead of a random master >>> image+serial shell. The agent will expose board identity, capabilities >>> and standard APIs to LAVA (notably the dispatcher). >>> The same API, if done sensibly, will work for software emulators and >>> hardware boards. Agent API for a software emulator can do different >>> things. Dispatcher should be based on agent API instead of ramming the >>> serial line. >>> >>> This sounds like a good connect topic. It has some advantages, but also >>> a lot of things to address. > > While I agree that a different implementation might be a nice thing, I > also see that it can be quite complicated and still not yet sure if > this will actually help much. > > I know serial is not the best interface you have, but it's the only > one that we know it works for all the boards we have :-) Once you > start relying on ethernet or such, then you can easily be blocked by > issues at the kernel/userspace side. > > Unfortunately it seems that serial is the most reliable interface you > may have with these boards. > >>> 3) The master image, as we know it today, should be booting remotely. >>> The boot loader can stay on the board until we can push it over USB. >>> em >>> >>> The problem is getting it to a state that we can push it over usb for >>> every board. Not all boards support this, and the ones that do >>> sometimes have issues with the tools to make it possible. >> >> I don't want to push 100% over usb but pushing 99.9 (all except to boot >> loader) works for all boards as far as I know. This would give us >> controllable master image (hell we could install tests before turning the >> power on). > > I guess this will only be an issue with Origen, as to make ethernet to > work at the boot loader you also need to have USB support (kind of > similar as Panda). For the others I believe it should just work (if > not, it's a bug). > > Cheers, > -- > Ricardo Salveti de Araujo > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
