On 12 July 2018 at 17:37, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 11 July 2018 at 05:21, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> I applied and quickly tested your series on a MIPS SoC I'm working on >> which has a tiny SRAM: >> >> (qemu) info mtree >> address-space: memory >> 0000000000000000-ffffffffffffffff (prio 0, i/o): system >> 0000000000000000-00000000000007ff (prio 0, ram): sram >> 0000000010000000-00000000107fffff (prio 0, i/o): pflash >> 0000000014000000-0000000014ffffff (prio 0, ram): dram >> 000000001fc00000-000000001fc0ffff (prio 0, rom): srom >> >> The firmware copies the ISR in this SRAM area, sadly it didn't work as >> expected: >> >> qemu-system-mips: Bad ram pointer 0x4a4
> Are you sure this is executing from the SRAM at this point? > The PC value in the backtrace is 2415932580 == 900034A4. I don't > know how the MMU is configured at this point, but my guess is that > that's actually in the pflash area, and you're running into a > different bug: > https://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg00674.html > where when we attempt to execute from a romd device that's in romd > mode we incorrectly think it's RAM in get_page_addr_code() and crash. I just sent a follow-on patch which should fix the 'bad ram pointer' assert. If your guest really is trying to execute from the pflash here then it will just misbehave in a different way, though, since pflash status response bytes are probably not valid MIPS instructions... thanks -- PMM
