[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
Re: [Qemu-devel] vexpress-a9: coreboot is unable to push any data on stack
Fri, 15 Aug 2014 17:10:04 +0100
On 15 August 2014 11:07, Piotr Król <address@hidden> wrote:
> Hi all,
> I'm trying to boot latest coreboot on qemu-system-arm (-M vexpress-a9).
> I compiled qemu arm-softmmu from source (latest code) and trying to boot
> qemu-system-arm -M vexpress-a9 -m 1024M -nographic -bios build/coreboot.rom
> First of all mtree looks strange because there are two aliases to one
> memory region:
> 0000000000000000-0000000003ffffff (prio 0, RW): alias vexpress.flashalias
> @vexpress.flash0 0000000000000000-0000000003ffffff
> 0000000000000000-0000000003ffffff (prio 0, RW): alias vexpress.lowmem
> @vexpress.highmem 0000000000000000-0000000003ffffff
> Is this ok ?
Well, yes and no. It's not intentional, but the effect is that
we'll happen to map the flash at address zero and ignore
the RAM alias.
I'm afraid when I put in the code to add the flash alias at
address zero I missed that the reason for it not being
already in the code was the legacy aliasing of RAM at zero.
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?
In terms of where we go from here, we have two
(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.