[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XenPPC] [PATCH] default link address



Perhaps we should, like Linux does, run early code to interface with FW
in a relocatable manner (perhaps even as a separately linked program)
and once we kill FW then we locate the HV code at any place we want.

Moving link addresses to accommodate a particular FW version means that
we may end up clashing with another instance of FW.

Such early FW-interface code would produce a Linux compatible DTC; and
Xen itself should only depend on that.  This will allow Xen to run on
any platform that supports Linux -- and note that platforms may support
Linux not by providing an actual OF instance, but rather by providing a
a DTC blob.

This would also allow us to play nice with kexec, which as a bonus would
allow for a scenario where we boot a Linux to do initial system set-up
and then kexec into Xen.   


-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>



On Fri, 2006-06-16 at 13:31 -0400, Amos Waterland wrote:
> Xen's current link address of 0x2000000 causes a program exception on
> JS20 blades with SLOF.  This patch changes the default link address
> to 0x3000000 (50MB) and adds some logic to allow LINK=X to be supplied
> at the make invocation.
> 
> This works for the JS20 and JS21 blades with SLOF that I have access to.
> Hopefully it works on Maple-D as well.
> 
> Signed-off-by: Amos Waterland <apw@xxxxxxxxxx>
> 
> ---
> 
>  Makefile |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff -r e427b4ae889f xen/arch/ppc/Makefile
> --- a/xen/arch/ppc/Makefile   Thu Jun 08 18:07:55 2006 -0400
> +++ b/xen/arch/ppc/Makefile   Fri Jun 16 13:18:23 2006 -0400
> @@ -75,11 +75,16 @@ physdev.o: ../x86/physdev.c
>  
>  HDRS += $(wildcard *.h)
>  
> +LINK = 0x3000000
> +boot32_link_base = $(LINK)
> +xen_link_offset  = 100
> +xen_link_base    = $(patsubst %000,%$(xen_link_offset),$(LINK))
> +
>  start.o: boot/start.S
>       $(CC) $(CFLAGS) -D__ASSEMBLY__ -c $< -o $@
>  
>  $(TARGET)-syms: start.o $(ALL_OBJS) xen.lds
> -     $(CC) $(CFLAGS) $(OMAGIC) -Wl,-Ttext,0x2000100,-T,xen.lds start.o 
> $(ALL_OBJS) -o $@
> +     $(CC) $(CFLAGS) $(OMAGIC) -Wl,-Ttext,$(xen_link_base),-T,xen.lds 
> start.o $(ALL_OBJS) -o $@
>  
>  $(TARGET).bin: $(TARGET)-syms
>       $(CROSS_COMPILE)objcopy --output-target=binary $< $@
> @@ -95,7 +100,7 @@ boot32.o: boot/boot32.S
>  
>  $(TARGET): boot32.o $(TARGET).bin.o
>       $(CC) -m32 -N -Wl,-melf32ppclinux -static -nostdlib \
> -             -Wl,-Ttext,0x2000000  -Wl,-Tdata,0x2000100 \
> +             -Wl,-Ttext,$(boot32_link_base)  -Wl,-Tdata,$(xen_link_base) \
>               $(CFLAGS) $^ -o $@
>  
>  asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c $(HDRS)
> 
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ppc-devel
> 


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.