On 10/10/2017 05:45 PM, Peter Maydell wrote: > On 10 October 2017 at 16:38, Cédric Le Goater <c...@kaod.org> wrote: >> On 10/10/2017 03:24 PM, Peter Maydell wrote: >>> On 10 October 2017 at 14:21, Cédric Le Goater <c...@kaod.org> wrote: >>>> On 10/10/2017 11:54 AM, Peter Maydell wrote: >>>>> The goal is to model hardware correctly. Hardware gives >>>>> aborts if you touch a physical address with no device there, >>>>> and so QEMU's model should do the same. If you have guest >>>>> code that touches a physical address and blows up because >>>>> of an abort (but doesn't when run on h/w) then either: >>>>> * it is trying to probe a device that exists in real h/w: >>>>> you need to provide a stub implementation in QEMU >>>>> * the SoC's bus fabric really doesn't pass aborts back >>>>> to the CPU; I think this is unlikely, but you can model >>>>> it at the SoC level with a suitable default memory region >>>> >>>> well, that is case it seems. >>> >>> If it is, then we should model the SoC that way, ie find >>> out from the hardware docs what part of the bus fabric >>> ignores decode errors and use memory regions with the >>> right default behaviour to cover the relevant address >>> ranges. >> >> The addresses generating memory fault errors are all in >> the region where the BMC SPI Flash Memory is mapped : >> [ 20000000-2FFFFFFF ] > > If there's an actual flash device there then this sounds > like my first case above, where we just need to stub out > that range of addresses until we get round to really > implementing the flash device.
but it is implemented ! and the region available. C.
