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

[Cédric Le Goater]

On 10/17/2017 05:39 PM, Peter Maydell wrote:
> On 13 October 2017 at 15:28, Cédric Le Goater <address@hidden> wrote:
>> The Witherspoon boards are OpenPOWER system hosting POWER9 Processors.
>> Let's add support for their BMC including a couple of I2C devices as
>> found on real HW.
>>
>> Signed-off-by: Cédric Le Goater <address@hidden>
>> Reviewed-by: Andrew Jeffery <address@hidden>
>> ---
>>
>>  Changes since v2:
>>
>>  - removed 'ignore_memory_transaction_failures' flag on the machine.
>>    Will require a couple of fixes in the legacy U-Boot accessing wrongly
>>    the bss before the DRAM is initialized.
>>
>>    The HW drops the write access surely because the SMC controller is
>>    configured in autoread mode by default. I don't know how to model
>>    this behavior in QEMU. I think we would need suppport to boot from
>>    a MMIO region.
> 
> It is actually possible now -- see hw/ssi/xilinx_spips.c and the
> request_mmio_ptr code. It's a bit experimental at the moment
> though (in particular it breaks migration, a thing which we
> seem to have forgotten to fix for this release cycle :-( )

I see. So the Aspeed SMC model would have to maintain a cache area 
of the flash device contents to satisfy the request_ptr() call ?   

> The other similar thing we have is the flash devices, which
> allow execution, but requires that the guest doesn't try to
> execute at the same time as it's put the flash into
> reads-like-a-device mode.
> 
> How are you modelling this bit of the address space at the moment?

The different flash devices are mapped on the AHB bus in ranges 
depending on the controller (and the SoC). For the AST2500, which 
is the witherspoon SoC, we have :

  [2000:0000-2FFF:FFFF]  BMC SPI Flash Memory
  [3000:0000-37FF:FFFF]  SPI1 Flash Memory
  [3800:0000-3FFF:FFFF]  SPI2 Flash Memory

The SoC boots from CS0 of the BMC SPI Controller which is also 
mapped at :

  [0000:0000-0FFF:FFFF]  Firmware SPI Memory (boot-up default)

Today, we  have created a ROM region which is filled with the 
CS0 flash content. See commit d769a1da342d ("aspeed: use first 
FMC flash as a boot ROM")

So we end up with address-space memory like this :

    0000000000000000-ffffffffffffffff (prio 0, i/o): system
      0000000000000000-0000000007ffffff (prio 0, rom): aspeed.boot_rom
      ...
      0000000020000000-000000002fffffff (prio 0, i/o): 
aspeed.smc.ast2500-fmc.flash
        0000000020000000-0000000027ffffff (prio 0, i/o): 
aspeed.smc.ast2500-fmc.0
        0000000028000000-0000000029ffffff (prio 0, i/o): 
aspeed.smc.ast2500-fmc.1
        000000002a000000-000000002bffffff (prio 0, i/o): 
aspeed.smc.ast2500-fmc.2
      0000000030000000-0000000037ffffff (prio 0, i/o): 
aspeed.smc.ast2500-spi1.flash
      ...   
  
This is a bit brutal, but it boots from the flash device. Booting 
from the MMIO region would be much better. I will take a look at it, 
but after some PPC work. 

> A "reads like RAM but writes are ignored" lump of memory is easy...

yes. It seems but I haven't found my way through :/ a stack trace
of the failure looks like this :

#0  0x00005555558c1680 in arm_cpu_do_transaction_failed (cs=0x5555568cfc00, 
physaddr=537117152, addr=209376, size=4, access_type=MMU_DATA_STORE, mmu_idx=3, 
attrs=..., response=2, retaddr=140737054425367)
    at target/arm/op_helper.c:241
#1  0x00005555557e36c6 in cpu_transaction_failed (retaddr=140737054425367, 
response=2, attrs=..., mmu_idx=3, access_type=MMU_DATA_STORE, size=4, 
addr=209376, physaddr=537117152, cpu=0x5555568cfc00)
    at include/qom/cpu.h:895
#2  0x00005555557e36c6 in io_writex (address@hidden, iotlbentry=<optimized 
out>, address@hidden, address@hidden, address@hidden, address@hidden, size=4) 
at accel/tcg/cputlb.c:825
#3  0x00005555557e73ef in io_writel (retaddr=140737054425367, addr=209376, 
val=4294967, index=204, mmu_idx=3, env=0x5555568d7e90) at 
accel/tcg/softmmu_template.h:265
#4  0x00005555557e73ef in helper_le_stl_mmu (env=0x5555568d7e90, 
addr=<optimized out>, val=4294967, oi=35, retaddr=140737054425367) at 
accel/tcg/softmmu_template.h:300
#5  0x00007fffe622c117 in code_gen_buffer ()
#6  0x00005555557eef8c in cpu_tb_exec (itb=<optimized out>, itb=<optimized 
out>, cpu=0x5555568d7e90)


> In any case we can deal with this as a later patchset.

Well, I would prefer fixing that little issue above with a workaround
region. 

Thanks,

C.