On 4/13/21 6:29 PM, Philippe Mathieu-Daudé wrote:> 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?
(In case you agree, no need to respin).