1Arm MPS2 and MPS3 boards (``mps2-an385``, ``mps2-an386``, ``mps2-an500``, ``mps2-an505``, ``mps2-an511``, ``mps2-an521``, ``mps3-an524``, ``mps3-an536``, ``mps3-an547``) 2========================================================================================================================================================================= 3 4These board models use Arm M-profile or R-profile CPUs. 5 6The Arm MPS2, MPS2+ and MPS3 dev boards are FPGA based (the 2+ has a 7bigger FPGA but is otherwise the same as the 2; the 3 has a bigger 8FPGA again, can handle 4GB of RAM and has a USB controller and QSPI flash). 9 10Since the CPU itself and most of the devices are in the FPGA, the 11details of the board as seen by the guest depend significantly on the 12FPGA image. 13 14QEMU models the following FPGA images: 15 16FPGA images using M-profile CPUs: 17 18``mps2-an385`` 19 Cortex-M3 as documented in Arm Application Note AN385 20``mps2-an386`` 21 Cortex-M4 as documented in Arm Application Note AN386 22``mps2-an500`` 23 Cortex-M7 as documented in Arm Application Note AN500 24``mps2-an505`` 25 Cortex-M33 as documented in Arm Application Note AN505 26``mps2-an511`` 27 Cortex-M3 'DesignStart' as documented in Arm Application Note AN511 28``mps2-an521`` 29 Dual Cortex-M33 as documented in Arm Application Note AN521 30``mps3-an524`` 31 Dual Cortex-M33 on an MPS3, as documented in Arm Application Note AN524 32``mps3-an547`` 33 Cortex-M55 on an MPS3, as documented in Arm Application Note AN547 34 35FPGA images using R-profile CPUs: 36 37``mps3-an536`` 38 Dual Cortex-R52 on an MPS3, as documented in Arm Application Note AN536 39 40Differences between QEMU and real hardware: 41 42- AN385/AN386 remapping of low 16K of memory to either ZBT SSRAM1 or to 43 block RAM is unimplemented (QEMU always maps this to ZBT SSRAM1, as 44 if zbt_boot_ctrl is always zero) 45- AN524 remapping of low memory to either BRAM or to QSPI flash is 46 unimplemented (QEMU always maps this to BRAM, ignoring the 47 SCC CFG_REG0 memory-remap bit) 48- QEMU provides a LAN9118 ethernet rather than LAN9220; the only guest 49 visible difference is that the LAN9118 doesn't support checksum 50 offloading 51- QEMU does not model the QSPI flash in MPS3 boards as real QSPI 52 flash, but only as simple ROM, so attempting to rewrite the flash 53 from the guest will fail 54- QEMU does not model the USB controller in MPS3 boards 55- AN536 does not support runtime control of CPU reset and halt via 56 the SCC CFG_REG0 register. 57- AN536 does not support enabling or disabling the flash and ATCM 58 interfaces via the SCC CFG_REG1 register. 59- AN536 does not support setting of the initial vector table 60 base address via the SCC CFG_REG6 and CFG_REG7 register config, 61 and does not provide a mechanism for specifying these values at 62 startup, so all guest images must be built to start from TCM 63 (i.e. to expect the interrupt vector base at 0 from reset). 64- AN536 defaults to only creating a single CPU; this is the equivalent 65 of the way the real FPGA image usually runs with the second Cortex-R52 66 held in halt via the initial SCC CFG_REG0 register setting. You can 67 create the second CPU with ``-smp 2``; both CPUs will then start 68 execution immediately on startup. 69 70Note that for the AN536 the first UART is accessible only by 71CPU0, and the second UART is accessible only by CPU1. The 72first UART accessible shared between both CPUs is the third 73UART. Guest software might therefore be built to use either 74the first UART or the third UART; if you don't see any output 75from the UART you are looking at, try one of the others. 76(Even if the AN536 machine is started with a single CPU and so 77no "CPU1-only UART", the UART numbering remains the same, 78with the third UART being the first of the shared ones.) 79 80Machine-specific options 81"""""""""""""""""""""""" 82 83The following machine-specific options are supported: 84 85remap 86 Supported for ``mps3-an524`` only. 87 Set ``BRAM``/``QSPI`` to select the initial memory mapping. The 88 default is ``BRAM``. 89