Re: [Qemu-devel] [PATCH v2 1/6] aspeed: add support for the witherspoon-bmc board

[Peter Maydell <peter.maydell@linaro.org>]

On 10 October 2017 at 16:38, Cédric Le Goater <clg@kaod.org> wrote:
> On 10/10/2017 03:24 PM, Peter Maydell wrote:
>> On 10 October 2017 at 14:21, Cédric Le Goater <clg@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.

thanks
-- PMM