On 24 January 2012 11:08, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
- Running a fast model on a 32bit VM is not practical, it seems to
crash after a few / dozen minutes due to insufficient address space
It kind of depends what workload you're giving it. A plain 32 bit guest should generally be OK. However the KVM work will require more address space than that anyway so we might as well standardise on 64 bit hosts from the start.
- I still have not managed to get autologin to work. This is mildly
annoying but should be possible to get over.
Issue on our side.
- A poweroff in the machine causes kernel panic
- A reboot in the machine seems to just hang and do nothing
We should be filing this kind of thing as bugs/enhancement requests through our official ARM support channel (for the avoidance of doubt, that's not me :-)).
- The system boots with nfsroot, the IP of the server and the
directory to mount is burned in the .axf file
I have a plan here, see below.
- An axf file is created from a kernel image and some other bits that
I don't yet understand. It seems that boot-wrapper is a kind of bootloader for linux in the fast model. I've found at least two sources for that [2] (from the wiki page by Peter Maydell) and [3] (from Michael Hope)
The official boot-wrapper sources come from git://git.ncl.cs.columbia.edu/pub/git/boot-wrapper
The boot-wrapper basically wraps up: * kernel * initrd (optionally) * kernel command line string * some trivial boot code to set up and launch the kernel into one AXF (ELF) file.
- I'm not at all sure why we need to cross compile qemu for arm (as
instructed in [4]) - is this so that we can test visualization support in a15?
This is because that wiki page is instructions for getting set up to test/develop KVM. So you don't need it to just run a simple system under the fast model. However we will need to set up something similar for doing validation testing of KVM: we will need to be able to build a QEMU, build a kvm-guest kernel, install the kvm-guest kernel and QEMU into the filesystem of the fast-model-guest and then launch the guest and then run LAVA tests on the guest.
- The instructions did miss a few things and I had to run apt-get -f
install / install extra cross packages. In the end I'm not sure how much of this is only required to build qemu, how much is required to build the rootfs and how much is required to build the kernel. It seems to be too messy ATM, I'd like to split this into separate problems that could be automated with standalone scripts we could fire in a VM or chroot (so that we are sure we got the dependencies right and everything really works fine)
Yes, automation is the general end plan. If there are bits of the wiki instructions that are not right please edit the wiki to correct them...
- I'm not at all sure what's the difference between model_shell's
terminal_[0123] and uart[0123]. That is, I'd like to know what those options do with a little bit more precision.
uart[0123] model the UARTs, ie the PL011 PrimeCells on a Versatile Express motherboard. terminal_[0123] are modelling a virtual terminal connected to the uart[0123] via a virtual RS232 cable.
From the user's point of view it doesn't make much difference,
it's just that some parameters happen to be on one component and some on the other depending on where the functionality they are controlling is implemented.
The major roadblock:
*) I'm still trying to parametrize the kernel command line. There seem to be a few possible ways to do it. One based on just rebuilding the axf file (longest/ugilest), one on changing the boot-wrapper bootloader to accept some extra data at the end and pass that down to the kernel (not my specialty, could take a moment to get to work), looking at model_shell -l output it seems there is a way to pass something known as 'cluster.cpu0.semihosting-cmd_line='. Perhaps that could be used to put some data that the kernel can read at runtime.
Yes, I have a plan to improve this. Rather than having bootwrapper include the kernel/initrd/commandline, we can have it use semihosting to read the files at runtime. So you would then be able to use the semihosting-cmd_line parameter to pass a string like "--kernel /path/to/uImage --initrd /path/to/initrd -- args for kernel" Then you would be able to build a single AXF file as a one-off step, and use the same AXF file for loading any kernel/initrd.
Might take me a few days to knock this together, though.
-- PMM