@@ -1,7 +1,7 @@
-Arm MPS2 and MPS3 boards (``mps2-an385``, ``mps2-an386``, ``mps2-an500``, ``mps2-an505``, ``mps2-an511``, ``mps2-an521``, ``mps3-an524``, ``mps3-an547``)
-=========================================================================================================================================================
+Arm MPS2 and MPS3 boards (``mps2-an385``, ``mps2-an386``, ``mps2-an500``, ``mps2-an505``, ``mps2-an511``, ``mps2-an521``, ``mps3-an524``, ``mps3-an536``, ``mps3-an547``)
+=========================================================================================================================================================================
-These board models all use Arm M-profile CPUs.
+These board models use Arm M-profile or R-profile CPUs.
The Arm MPS2, MPS2+ and MPS3 dev boards are FPGA based (the 2+ has a
bigger FPGA but is otherwise the same as the 2; the 3 has a bigger
@@ -13,6 +13,8 @@ FPGA image.
QEMU models the following FPGA images:
+FPGA images using M-profile CPUs:
+
``mps2-an385``
Cortex-M3 as documented in Arm Application Note AN385
``mps2-an386``
@@ -30,6 +32,11 @@ QEMU models the following FPGA images:
``mps3-an547``
Cortex-M55 on an MPS3, as documented in Arm Application Note AN547
+FPGA images using R-profile CPUs:
+
+``mps3-an536``
+ Dual Cortex-R52 on an MPS3, as documented in Arm Application Note AN536
+
Differences between QEMU and real hardware:
- AN385/AN386 remapping of low 16K of memory to either ZBT SSRAM1 or to
@@ -45,6 +52,30 @@ Differences between QEMU and real hardware:
flash, but only as simple ROM, so attempting to rewrite the flash
from the guest will fail
- QEMU does not model the USB controller in MPS3 boards
+- AN536 does not support runtime control of CPU reset and halt via
+ the SCC CFG_REG0 register.
+- AN536 does not support enabling or disabling the flash and ATCM
+ interfaces via the SCC CFG_REG1 register.
+- AN536 does not support setting of the initial vector table
+ base address via the SCC CFG_REG6 and CFG_REG7 register config,
+ and does not provide a mechanism for specifying these values at
+ startup, so all guest images must be built to start from TCM
+ (i.e. to expect the interrupt vector base at 0 from reset).
+- AN536 defaults to only creating a single CPU; this is the equivalent
+ of the way the real FPGA image usually runs with the second Cortex-R52
+ held in halt via the initial SCC CFG_REG0 register setting. You can
+ create the second CPU with ``-smp 2``; both CPUs will then start
+ execution immediately on startup.
+
+Note that for the AN536 the first UART is accessible only by
+CPU0, and the second UART is accessible only by CPU1. The
+first UART accessible shared between both CPUs is the third
+UART. Guest software might therefore be built to use either
+the first UART or the third UART; if you don't see any output
+from the UART you are looking at, try one of the others.
+(Even if the AN536 machine is started with a single CPU and so
+no "CPU1-only UART", the UART numbering remains the same,
+with the third UART being the first of the shared ones.)
Machine-specific options
""""""""""""""""""""""""
Add documentation for the mps3-an536 board type. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- docs/system/arm/mps2.rst | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-)