[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] mps3-an524: support memory remapping
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH 0/3] mps3-an524: support memory remapping |
Date: |
Mon, 12 Apr 2021 16:37:51 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
Hi Peter,
On 4/12/21 3:43 PM, Peter Maydell wrote:
> The AN524 FPGA image supports two memory maps, which differ
> in where the QSPI and BRAM are. In the default map, the BRAM
> is at 0x0000_0000, and the QSPI at 0x2800_0000. In the second
> map, they are the other way around.
>
> In hardware, the initial mapping can be selected by the user
> by writing either "REMAP: BRAM" (the default) or "REMAP: QSPI"
> in the board configuration file. The guest can also dynamically
> change the mapping via the SCC CFG_REG0 register.
>
> This patchset adds support for the feature to QEMU's model;
> the user-sets-the-initial-mapping part is a new machine property
> which can be set with "-M remap=QSPI".
>
> This is needed for some guest images -- for instance the
> Arm TF-M binaries -- which assume they have the QSPI layout.
I tend to see machine property set on the command line similar
to hardware wire jumpers, externally set (by an operator having
access to the hardware, not guest code).
Here the remap behavior you described is triggered by the guest.
Usually this is done by a bootloader code before running the
guest code.
Couldn't we have the same result using a booloader (like -bios
cmd line option) rather than modifying internal peripheral state?
I'm worried anyone wants to add its own machine property to simplify
device modelling, but maybe this is the correct way to go...
Regards,
Phil.