Mailing List Archive: [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM

[PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM

Sep 3, 2012, 6:28 AM

Post #1 of 5 (168 views)

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

Re: [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM [ In reply to ]

david.vrabel at citrix

Sep 6, 2012, 7:46 AM

Post #2 of 5 (158 views)

Permalink

On 03/09/12 14:28, Ian Campbell wrote:
> 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.

Until there is an agreement on this protocol I would prepend a "xen,"
prefix to the node names (xen,nr-modules etc.).

bootargs instead of args would be more consistent perhaps. So,
module1-args becomes xen,module1-bootargs.

The proposed protocol is functional and useful using nodes for each
module seems to be more device-tree-ish. I think in the longer term,
perhaps something like the following would be better?

chosen {
module@1 {
compatible = "multiboot-module";
regs = <0x12345678 0x01000>;
bootargs = "frob";
};
module@2 {
compatible = "multiboot-module";
regs = <0x12345678 0x01000>;
}
}

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM [ In reply to ]

Ian.Campbell at citrix

Sep 10, 2012, 9:12 AM

Post #3 of 5 (157 views)

Permalink

On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> On 03/09/12 14:28, Ian Campbell wrote:
> > 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.
>
> Until there is an agreement on this protocol I would prepend a "xen,"
> prefix to the node names (xen,nr-modules etc.).

OK.

> bootargs instead of args would be more consistent perhaps. So,
> module1-args becomes xen,module1-bootargs.
>
> The proposed protocol is functional and useful using nodes for each
> module seems to be more device-tree-ish. I think in the longer term,
> perhaps something like the following would be better?

I rather suspect I'm going to end up porting multiboot to ARM. But you
are right that this looks like a better DTish way than mine.

>
> chosen {
> module@1 {

Are these normally 1 based or 0 based in DT?

> compatible = "multiboot-module";
> regs = <0x12345678 0x01000>;

Is this start and length? This relates somehow to #address-cells or
something doesn't it?

> bootargs = "frob";
> };
> module@2 {
> compatible = "multiboot-module";
> regs = <0x12345678 0x01000>;
> }
> }
>
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM [ In reply to ]

stefano.stabellini at eu

Sep 17, 2012, 4:39 AM

Post #4 of 5 (153 views)

Permalink

On Mon, 10 Sep 2012, Ian Campbell wrote:
> On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> > On 03/09/12 14:28, Ian Campbell wrote:
> > > 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.
> >
> > Until there is an agreement on this protocol I would prepend a "xen,"
> > prefix to the node names (xen,nr-modules etc.).
>
> OK.
>
> > bootargs instead of args would be more consistent perhaps. So,
> > module1-args becomes xen,module1-bootargs.
> >
> > The proposed protocol is functional and useful using nodes for each
> > module seems to be more device-tree-ish. I think in the longer term,
> > perhaps something like the following would be better?
>
> I rather suspect I'm going to end up porting multiboot to ARM. But you
> are right that this looks like a better DTish way than mine.

I think that the grub folks have already extended the original spec to
make it easier to port to other archs.
Give a look at include/multiboot2.h, it seems to support mips as well as
x86.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 0/16] arm: support for initial modules (e.g. dom0) and DTB supplied in RAM [ In reply to ]

Ian.Campbell at citrix

Oct 11, 2012, 7:57 AM

Post #5 of 5 (149 views)

Permalink

On Mon, 2012-09-03 at 14:28 +0100, Ian Campbell wrote:
> The following series implements support for initial images and DTB in
> RAM

A subset of these patches have been acked so I have applied them. They
are generally cleanups rather than the main boot-wrapper stuff.
arm: Zero the BSS at start of day.
arm: make virtual address defines unsigned
arm: move get_paddr_function to arch setup.c from device_tree.c
arm: really allocate boot frametable pages with 32M alignment
arm: print a message if multiple banks of memory are present.
arm: mark heap and frametable limits as read mostly

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel