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

[Julien Grall <julien.grall@xxxxxxx>]

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.
It will be fairly easy to sanitize or even fix it. I will send a patch 
for it.
Cheers,

--
Julien Grall

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