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@lists.xen.org
http://lists.xen.org/xen-devel
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@lists.xen.org
http://lists.xen.org/xen-devel