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 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
FPGA again, can handle 4GB of RAM and has a USB controller and QSPI flash).

Since the CPU itself and most of the devices are in the FPGA, the
details of the board as seen by the guest depend significantly on the
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``
  Cortex-M4 as documented in Arm Application Note AN386
``mps2-an500``
  Cortex-M7 as documented in Arm Application Note AN500
``mps2-an505``
  Cortex-M33 as documented in Arm Application Note AN505
``mps2-an511``
  Cortex-M3 'DesignStart' as documented in Arm Application Note AN511
``mps2-an521``
  Dual Cortex-M33 as documented in Arm Application Note AN521
``mps3-an524``
  Dual Cortex-M33 on an MPS3, as documented in Arm Application Note AN524
``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
  block RAM is unimplemented (QEMU always maps this to ZBT SSRAM1, as
  if zbt_boot_ctrl is always zero)
- AN524 remapping of low memory to either BRAM or to QSPI flash is
  unimplemented (QEMU always maps this to BRAM, ignoring the
  SCC CFG_REG0 memory-remap bit)
- QEMU provides a LAN9118 ethernet rather than LAN9220; the only guest
  visible difference is that the LAN9118 doesn't support checksum
  offloading
- QEMU does not model the QSPI flash in MPS3 boards as real QSPI
  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
""""""""""""""""""""""""

The following machine-specific options are supported:

remap
  Supported for ``mps3-an524`` only.
  Set ``BRAM``/``QSPI`` to select the initial memory mapping. The
  default is ``BRAM``.