Hi Peter, On 4/12/21 4:48 PM, Peter Maydell wrote: > On Mon, 12 Apr 2021 at 15:37, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> 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. OK now I understand the picture, the MCC is external. In that case the machine property is a clean way to address that. Could you add the first paragraph of your answer ([*]) in patch 3 description (before the current comment) to make it clearer? Thanks for the clarification, Phil.