[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM
The following series implements support for initial images and DTB in RAM, as opposed to in flash (dom0 kernel) or compiled into the hypervisor (DTB). It arranges to not clobber these with either the h/v text on relocation or with the heaps and frees them as appropriate. Most of this is independent of the specific bootloader protocol which is used to tell Xen where these modules actually are, but I have included a simple PoC bootloader protocol based around device tree which is similar to the protocol used by Linux to find its initrd (where /chosen/linux,initrd-{start,end} indicate the physical address). In the PoC the modules are listed in the chosen node starting with /chosen/nr-modules which contains the count and then /chosen/module %d-{start,end} which gives the physical address of the module and /chosen/module%d-args which give its command line. I will post a patch against the boot-wrapper[0] which implements the "bootloader" side of this protocol shortly. With that you can boot using the semi-hosting feature of the model (paths are host paths) like so: $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\ '--kernel xen-arm.bin \ --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \ --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M' Until we know what bootloaders are going to become common in the ARM servers world it hard to know who we should be working with to define a proper protocol going forward and which bootloaders to supply patches for. (see the mail with the boot-wrapper patch for more on this). I suspect that we will inevitably need a tool which takes Xen and the modules and builds them into a single self exploding image since bootloader support for any protocol we end up defining is likely to be spotty at least for the time being. One thing I'm wondering is whether or not we should duplicate the Linux zImage header (magic numbers, length etc) at the start of our image too. That is this: start: .type start,#function .rept 7 mov r0, r0 .endr ARM( mov r0, r0 ) ARM( b 1f ) THUMB( adr r12, BSYM(1f) ) THUMB( bx r12 ) .word 0x016f2818 @ Magic numbers to help the loader .word start @ absolute load/run zImage address .word _edata @ zImage end address THUMB( .thumb ) 1: mov r7, r1 @ save architecture ID mov r8, r2 @ save atags pointer It's pretty trivial but I'm not sure of how much use it is. [0] git://git.linaro.org/arm/models/boot-wrapper.git _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |