On 15 August 2014 11:07, Piotr Król <pietrush...@gmail.com> 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 > with: > > 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 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. thanks -- PMM
