W dniu 08.12.2011 02:54, Ricardo Salveti pisze:
On Wed, Dec 7, 2011 at 4:36 PM, Zygmunt Krynicki zygmunt.krynicki@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.krynicki@linaro.orgmailto:zygmunt.krynicki@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'mThis 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