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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


> 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?

> > +
> >  #define PT_PT  0xe7f /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=1, P=1 
> > */
> >  #define PT_MEM 0xe7d /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=0, P=1 
> > */
> >  #define PT_DEV 0xe71 /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=100, T=0, P=1 
> > */
> > @@ -52,6 +55,18 @@
> >      * or the initial pagetable code below will need adjustment. */
> >     .global start
> >  start:
> > +
> > +   .rept   7
> > +   mov     r0, r0
> > +   .endr
> > +   mov     r0, r0
> > +   b       1f
> > +
> > +   .word   ZIMAGE_MAGIC_NUMBER                             @ Magic numbers 
> > to help the loader
> > +   .word   (_start + XEN_PHYS_ADDRESS)             @ absolute load/run 
> > zImage address
> 
> Wacky spaces?

No, they are all tabs, that's why they look out of place here

> 
> > +   .word   (_end + XEN_PHYS_ADDRESS)               @ zImage end address
> > +
> > +1:
> >     cpsid aif                    /* Disable all interrupts */
> >  
> >     /* Save the bootloader arguments in less-clobberable registers */
> 
> 
> 

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