Re: [Xen-devel] [PATCH] xen/arm: build as zImage

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-11-23 at 16:14 +0000, Stefano Stabellini wrote:
> On Fri, 23 Nov 2012, Ian Campbell wrote:
> > On Fri, 2012-11-23 at 15:45 +0000, Stefano Stabellini wrote:
> > > The zImage format is extremely simple: it only consists of a magic
> > > number and 2 addresses in a specific position (see
> > > http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#d0e309).
> > > 
> > > Some bootloaders expect a zImage; considering that it doesn't cost us
> > > much to build Xen compatible with the format, make it so.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > > 
> > > 
> > > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > > index 25c4cfe..de9cdb2 100644
> > > --- a/xen/arch/arm/head.S
> > > +++ b/xen/arch/arm/head.S
> > > @@ -22,6 +22,9 @@
> > >  #include <asm/processor-ca15.h>
> > >  #include <asm/asm_defns.h>
> > >  
> > > +#define ZIMAGE_MAGIC_NUMBER 0x016f2818
> > > +#define XEN_PHYS_ADDRESS    0x80000000
> > 
> > This is platform specific. AIUI you can put 0 in the field and the boot
> > loader is expected to do something sensible, although that might require
> > a new enough bootloader (FSVO new enough).
> 
> It is expected to work with bootloaders other than U-Boot?  My guess is
> that it could work with U-Boot, because it uses its own format on top of
> zImage, but that it won't probably work with anything else, for example
> UEFI/arm, that at the moment seems to support only zImage.

I thought this was a feature of zImage not u-boot, u-boot has its own
header and ignores this field I think.

http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
says:
        The start address is usually 0 as the zImage code is position
        independent.
        
Of course this has to be true in the modern multiplatform zImage world.

Looking at a random zImage:
        000000 e1a00000 e1a00000 e1a00000 e1a00000
        *
        000020 ea000002 016f2818 00000000 00220548
        
Where 016f2818 is the magic, 0 is the start and 220548 is the
end/length.

I knew I didn't imagine it ;-)

> > If that doesn't work then this constant is actually in
> > xen/arch/arm/Makefile too and for the same reason:
> >         # XXX: VE model loads by VMA so instead of
> >         # making a proper ELF we link with LMA == VMA and adjust crudely
> >         $(OBJCOPY) --change-addresses +0x80000000 $< $@
> >         $(STRIP) $@
> > 
> > How about making this CONFIG_PHYSICAL_LOCAL_ADDR and plumbing through
> > like we do with CONFIG_DTB_FILE?
> 
> Yeah, I was thinking about that.
> However in this case we would want to set the default somewhere, rather
> than forcing the user to specify it.
> Also we would need to export CONFIG_PHYSICAL_LOCAL_ADDR to a generated
> header file somewhere. Do you have any suggestions on where?

For the DTB we just do:
ifdef CONFIG_DTB_FILE
AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
else
..

If indeed we need this then we should do it the same way, and probably
set the default == 0.

Ian


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