[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


  • To: xen-devel <xen-devel@xxxxxxxxxxxxx>
  • From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  • Date: Mon, 3 Sep 2012 14:28:06 +0100
  • Delivery-date: Mon, 03 Sep 2012 13:28:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.