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