Re: [PATCH 0/3] mps3-an524: support memory remapping

[Peter Maydell]

On Mon, 12 Apr 2021 at 15:37, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> 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?

In the real hardware, the handling of the board configuration
file is done by the "Motherboard Configuration Controller", which
is an entirely separate microcontroller on the dev board but outside
the FPGA, and which is responsible for things like loading image
files off the SD card and writing them to memory, setting a bunch
of initial configuration including the remap setting but also
things like setting the oscillators to the values that this
particular FPGA image needs. It's also what makes the board
appear to a connected computer as a USB mass storage device so
you can update the SD card files via USB cable rather than doing
lots of plugging and unplugging, and it is what loads the FPGA
image off SD card and into the FPGA in the first place.

QEMU is never going to implement the MCC as a real emulated
guest CPU; instead our models hard-code some of the things it
does. I think that a machine property (a thing set externally
to the guest CPU and valid before any guest CPU code executes)
is a reasonable way to implement the remap setting, which from
the point of view of the CPU inside the FPGA is a thing set
externally and valid before any guest CPU code executes.

thanks
-- PMM