docs/system/arm/mps2.rst | 10 ++++ include/hw/misc/mps2-scc.h | 21 ++++++++ hw/arm/mps2-tz.c | 106 ++++++++++++++++++++++++++++++++++++- hw/misc/mps2-scc.c | 13 +++-- 4 files changed, 146 insertions(+), 4 deletions(-)
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.
Based-on: 20210409150527.15053-1-peter.maydell@linaro.org
("mps3-an524: Fix MPC setting for SRAM block")
though any conflict/dependency would be minor and purely textual.
thanks
-- PMM
Peter Maydell (3):
hw/misc/mps2-scc: Add "QEMU interface" comment
hw/misc/mps2-scc: Support using CFG0 bit 0 for remapping
hw/arm/mps2-tz: Implement AN524 memory remapping via machine property
docs/system/arm/mps2.rst | 10 ++++
include/hw/misc/mps2-scc.h | 21 ++++++++
hw/arm/mps2-tz.c | 106 ++++++++++++++++++++++++++++++++++++-
hw/misc/mps2-scc.c | 13 +++--
4 files changed, 146 insertions(+), 4 deletions(-)
--
2.20.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.
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
Hi Peter, On 4/12/21 4:48 PM, Peter Maydell wrote: > On Mon, 12 Apr 2021 at 15:37, Philippe Mathieu-Daudé <f4bug@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.
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é <f4bug@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).
On 4/12/21 6:43 AM, Peter Maydell wrote: > Peter Maydell (3): > hw/misc/mps2-scc: Add "QEMU interface" comment > hw/misc/mps2-scc: Support using CFG0 bit 0 for remapping > hw/arm/mps2-tz: Implement AN524 memory remapping via machine property Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
© 2016 - 2024 Red Hat, Inc.