Hi.
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. 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. 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.
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)
The rest of lava is now related to managing resources and misc tasks: - running model_shell instances and their 'serial lines' - unpacking and blessing nfs root directories (blessing = patching it enough to make the model boot and work for us) - exporting nfsroot directories for the local network (currently hardcoded as 192.168.0.0/24 - managing local library of models (building, enumerating, adding/removing) - managing root to do the things required.
I'm still not done but I hope to push this to one of our servers this week. Ideally I'd like to try on a virtual machine to see how that setup copes with the code. In addition I want to ensure I don't put any magic there, and that all of the installation is managed by automation tools. Thanks ZK
PS: After spending the weekend looking at my scripts crashing I took a break. On Monday, today, I grabbed Peter to troubleshoot the issue. The issue was gone, I have no idea what changed (perhaps my long-lived terminal accumulated some cruft).