[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/arm: build as zImage
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |