qemu-arm
[Top][All Lists]
Advanced

[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. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]