[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/6] aspeed: add support for the witherspoon-
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/6] aspeed: add support for the witherspoon-bmc board |
Date: |
Tue, 10 Oct 2017 17:54:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/10/2017 05:45 PM, Peter Maydell wrote:
> On 10 October 2017 at 16:38, Cédric Le Goater <address@hidden> wrote:
>> 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 ]
>
> 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.