W dniu 08.12.2011 02:54, Ricardo Salveti pisze:
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.
I'll dig into it next week
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.
I'll report bugs on all my findings.
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.
I don't want to use serial the same way we use it right now. That is, by
running everything on a root shell with pyexpect fueling the process.
There _are_ better ways, mostly based on bidirectional packeted
transport interfaces. The same rules apply to USB actually.
Anyway, if you assume that anything we do runs without networking then
you'd be surprised. We require master images to have networking right
now. For test images we can still kind of make it without having a
working connection but IMHO that's a moot point since master image
usually has to work first and I can count on my hand the number of times
we had broken network in test images and good network in master images.
Then there is pppd which would give us networking without USB.
Unfortunately it seems that serial is the most reliable interface you
may have with these boards.
Sure, then let's use it in a less brute-force way than pyexpect.
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).
Getting it to work with panda would be a major milestone. I don't treat
boards as equal as they are not equal. Last time I checked uboot has
lots of USB and ethernet support so we might be able to eventually do it
assuming actual bugs in both linux kernel and uboot for origen are fixed.
Best regards
Zygmunt
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
