Re: [Xen-devel] ARM bare metal application test

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, May 09, 2016 at 06:57:13PM +0100, Julien Grall wrote:
> 
> 
> On 09/05/16 18:39, Wei Liu wrote:
> >On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
> >>
> >>
> >>On 09/05/16 17:43, Ivan Pavić2 wrote:
> >>>Hello Julien,
> >>
> >>Hello Ivan,
> >>
> >>>
> >>>Julien Grall wrote:
> >>>>Guest are booting with MMU disabled, so 0x80008000 will be the physical
> >>>>address.
> >>>
> >>>>The toolstack will load the kernel at this physical address. However,
> >>>>the start of the guest RAM for Xen 4.7 is 0x40000000 (see
> >>>>include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
> >>>>address?
> >>>
> >>>I changed address. It seems the problem is solved because PC is now
> >>>40008030 (that is address of "work: b work" i think).
> >>
> >>You can figure out the associated instruction with objdump.
> >>
> >>>
> >>>>By the way, how much RAM did you give to the guest?
> >>>
> >>>I wrote "memory = 32" in cfg file, I think that stands for 32 MB?
> >>
> >>Correct, so the end of the RAM bank would be 0x42000000. I am a bit
> >>surprised that the toolstack does not complain when trying to load the
> >>kernel at 0x80008000.
> >>
> >
> >I don't think toolstack tries to load kernel to that guest physical
> >address -- reading from Ivan's log it suggests toolstack loaded the
> >kernel to 0x40008000.
> >
> >That (0x8000800) is the address set in PC, right?  I don't think
> >toolstack is in a position to sanitise that nor should it care.
> 
> The zImage format offers the opportunity to either choose the base address
> or let the loader do it for you.
> 
> Based on the specification, this address is supposed to be both the PC and
> the loading address. However, libxc (see xc_dom_parse_zimage32_kernel) seems
> to handle the first case incorrectly.
> 

 99     /*                                                                      
    
100      * If start is invalid then the guest will start at some invalid
101      * address and crash, but this happens in guest context so doesn't
102      * concern us here.
103      */
104     start = zimage[ZIMAGE32_START_OFFSET/4];

It looks like the comment agrees with me.  But at the end of the day it
is your call to determine what is the correct behaviour.

> It will be fairly easy to sanitize or even fix it. I will send a patch for
> it.
> 

Cool, thanks.

Though I suspect you also need to work out how rambase is arranged so it
might not be as simple as you thought. :-/

Wei.

> Cheers,
> 
> -- 
> Julien Grall

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