[XenPPC] Loading at a different address, Was: [PATCH] Xen load address

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

Hey Amos,
The problem with the link address is that SLOF loads all tftp images  
to 0x2000000 then SLOFs ELF loader kicks in and writes the load image  
on top of the ELF image, nice eh?
That link address has been chosen because we were told that PIBS  
expects it there, I'd be happy to change the link address if it does  
not break maple, but it looks like the new address is no good for  
JS20 (as you mention below)
The SLOF on JS21 workaround is:
  s" netboot 3000000 1000000" snk
  3000000 load-elf-file start-elf

I think the "snk" is the file name but I'm not sure.

Hopefully SLOF can at some point recognize the loading issue and  
perhpas copy the ELF image elsewhere before it interprets it.
On Jun 15, 2006, at 12:32 AM, Amos Waterland wrote:

> I get this when trying to boot Xen on JS21+SLOF, where I'm using your
> link address of 0x2000000:
>
>  ( 700 )  Program Exception
>      CR / XER           LR / CTR          SRR0 / SRR1        DAR /  
> DSISR
>          22000082   00000000011102a0   0000000000000000    
> 0000000000000000
>  0000000000000006   0000000000000000   1000000000083000            
> 00000000
> So changing the link address to 0x2800000 produces:
>
>  ( 700 )  Program Exception
>      CR / XER           LR / CTR          SRR0 / SRR1        DAR /  
> DSISR
>          22000082   0000000002800138   0000000000000000    
> 0000000000000000
>  0000000020000006   0000000000000000   9000000000081000            
> 00000000
> At least the link register makes sense in the second case.  I am  
> curious
> about how it got loaded with 0x11102a0 in the default case.
>
> Anyway, the below patch (not for submission) lets me boot up to this:
>
>  OF: Xen/PPC version 3.0-unstable (apw@xxxxxxxxxxxxxx) (gcc version  
> 4.1.1 ())
>  boot_of_init args: 0x0 0x0 0x111027c 0x0 0x0
>  boot msr: 0x1000000000003000
>  boot_of_init: _start 0000000003000100 _end 0000000003acb9a0 0x0
>  boot_of_probemem: memory 0x0000000000000000[0x80000000]
>  bootargs = xen console=com1 -- init=/bin/bash iommu=off
>  DOM0 bootargs = dom0 init=/bin/bash iommu=off
>  boot_of_module: linked in module copied after _end \
>   (start 0x000000000306794c size 0xa34620)
>  find_space base=0x0000000003acb9a0  eomem=0x0000000080000000  \
>   size=0x00a34620  align=0x1000
>  No space to copy mod0
>
> Note that 0x3000000 will not work on my JS20 (prints 'No space to  
> copy mod0'),
> while 0x2000000 does work.
wow how big is the Dom0?

> I'm going to try to track down the 'No space to copy mod0' problem on
> the JS21.
hmm.. I'm not sure if this is a problem,  I can't recall why we copy  
dom0 I think its just to satisfy the multi-boot stuff.
I think it would be better to leave the link address as is.


> If you have any ideas please comment.


> ---
>
> 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     Thu Jun 15 00:28:07 2006 -0400
> @@ -75,11 +75,14 @@ physdev.o: ../x86/physdev.c
>
>  HDRS += $(wildcard *.h)
>
> +boot32_link_base = 0x3000000
> +xen_link_base    = 0x3000100
> +
>  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 +98,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