[Top][All Lists]

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

Re: [Qemu-devel] vexpress-a9: coreboot is unable to push any data on sta

From: Piotr Król
Subject: Re: [Qemu-devel] vexpress-a9: coreboot is unable to push any data on stack
Date: Fri, 15 Aug 2014 20:02:24 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Aug 15, 2014 at 05:10:04PM +0100, Peter Maydell wrote:
> For your stack issues, it looks like your code is trying to
> use the area which is the flash as the stack. Since flash
> isn't writeable, we ignore the writes and it's not very
> useful for stack. It looks like your code is assuming that
> the low memory is RAM, not flash -- so how does your
> code work on real hardware? Do you try to use the
> software controllable remapping to copy from the flash
> into RAM before using the stack, or something else?

Peter thanks for your reply. I'm not coreboot developer so cannot
advocate for their decision. Bootblock that I sent is from build
targeted on qemu and developer who initially wrote the code suggest
using it with '-kernel' parameter. I would like to fix this code
according to correct memory map.

Comment in hw/arm/vexpress.c say that, as you wrote below, Versatile
Express got two possible memory maps. Can you point me to exact
documentation that you use as reference for vexpress implementation ?

> In terms of where we go from here, we have two
> choices:
>  (1) leave address 0 as RAM, not flash; this means
> legacy guest binaries that work only on QEMU and
> not on real hardware will still work, but the -bios
> option won't be of much use. (This is more or less
> reverting to the 2.0 situation.)
>  (2) bring it in to line with vexpress-a15 (which is
> effectively how 2.1 shipped), so 0 is always flash
> and never RAM. This is consistent but (as you've
> found) binaries assuming that 0 is a RAM alias
> will stop working.

Assuming option (2) contain strategy for future releases it should be
priority. I will try to fix coreboot binary according to this advice.

One more time thanks for explanation.

Piotr Król

reply via email to

[Prev in Thread] Current Thread [Next in Thread]