[Linaro-validation] Second update on fast models
zygmunt.krynicki at linaro.org
Tue Feb 14 19:24:51 UTC 2012
On Tue, Feb 14, 2012 at 3:26 AM, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> On Mon, 13 Feb 2012 22:27:25 +0100, Zygmunt Krynicki <zygmunt.krynicki at linaro.org> wrote:
>> Fast model support is getting better. It seems that with the excellent
>> patches by Peter Maydell we can now boot some kernels (I've only tried
>> one tree, additional trees welcome :-). I'm currently building a
>> from-scratch environment to ensure everything is accounted for and I
>> understand how pieces interact.
>> Having said that I'd like to summarize how LAVA handles fast models:
>> Technically the solution is not unlike QEMU which you are all familiar
>> with. The key differences are:
>> 1) Only NFS boot makes sense. There are no other sensible method that
>> I know of. We may also use a SD card (virtual obviously) but it is
>> constrained to two gigabytes of data.
> As mentioned in the other thread, it would be good to at least let ARM
> know that removing this limit would help us (if we can figure out how to
> do this).
We may figure out how to do this by reading the LISA source code that
came with the model. That's a big task though (maybe grepping for mmc0
is a low hanging fruit, I did not check)
>> 2) The way we actually boot is complicated. There is no uboot, fast
>> model interpreter actually starts an .axf file that can do anything
>> (some examples include running tests and benchmarks without actually
>> setting the kernel or anything like that). There is no way to easily
>> load the kernel and pass a command line. To work around that we're
>> using a special axf file that uses fast model semihosting features to
>> load the kernel/initrd from a host filesystem as well as to setup the
>> command line that will be passed to the booting kernel. This allows us
>> to freely configure NFS services and point our virtual kernel at
>> appropriate IP addresses and pathnames.
> So I guess I'd like to understand how this works in a bit more detail.
> Can you brain dump on the topic for a few minutes? :) What is "fast
> model semihosting"?
It's a way to have "syscalls" that connect the "bare hardware" (be it
physical or emulated) to an external debugger or other monitor. You
can find a short introduction in this blog . For us it means we get
to write bare-metal assembly that does the equivalent of open(),
read(), write() and close(). The files are being opened are on the
machine that runs the fast model. You can also print debugging
statements straight to the console this way (we probably could write
semihosting console driver if there is no such code yet) to get all of
the output to the same tty that runs the model (model_shell). A more
detailed explanation of this topic can be found in 
Fast model semihosting simply refers to using semihosting facilities
in a fast model interpreter.
>> 3) After the machine starts up we immediately open a TPC/IP connection
>> to a local TCP socket. We know which port is being used so we can
>> easily allocate them up front. This port is now the traditional LAVA
>> serial console.
> I guess there is a risk here that we will miss early boot messages?
> This might not matter much.
There are other options but currently this seems to work quite okay.
> Once we've found someone at ARM we can officially complain at about fast
> models, an option to have serial comms happen on the process
> stdin/stdout would be nice.
I think the reason they don't happen in the console is that by default
we get four telnet ports to connect to (definitely more than one) so
the logical question they'll ask is "which port should we redirect".
Maybe there is an option buried somewhere to make that happen but so
far I have not found it.
>> The rest of this looks like QEMU:
>> - you can access the filesystem easily (to gather results)
>> - we can use QEMU to chroot into the NFS root to install additional
>> software (emulation via a fast model is extremely slow)
> In my testing, the pip install bzr+lp:lava-test step did not really work
> under QEMU. Maybe it does now, or maybe we can install a tarball or
I installed lava-test using release tarball. That has worked pretty well.
In general I think that:
1) We need to reconsider how to do testing on very slow machines
2) What can be invoked on the host (part of installation, unless that
wants to build stuff, result parsing and tracking)
3) What has to be invoked on the target (test code, system probes)
It's important to make the intent very clear. If we define that
cmd_install installs something while in "master image" on the "target"
then we should not break that. I think that it would be sensible to
add "host_chroot" mode that applies nicely to qemu and fast models.
Very slow things that don't care about the architecture could be
invoked in that mode without sacrificing performance.
More information about the linaro-validation