[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v2 1/6] aspeed: add support for the witherspoon-bm
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-arm] [PATCH v2 1/6] aspeed: add support for the witherspoon-bmc board |
Date: |
Tue, 10 Oct 2017 17:38:31 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/10/2017 03:24 PM, Peter Maydell wrote:
> On 10 October 2017 at 14:21, Cédric Le Goater <address@hidden> 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 ]
but we should not be doing any writes there. I will make
some inquiries.
Thanks,
C.