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