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. Thanks, Piotr Król
