Model the MPS3-AN536 dual-Cortex-R52 FPGA image

We currently have a CPU model of the Cortex-R52, which is an AArch32 Arm-v8R CPU. However, we don't have any board types which use it. This Epic proposes to add a model of the MPS3 FPGA image AN536, which is an example dual-R52 system, as documented here: https://developer.arm.com/documentation/dai0536/

Deliverables

Board model “mps3-an536” for use by projects such as Xen and possibly Zephyr as a target for porting and testing AArch32 v8R code.

Out of Scope

We plan to model this to a similar level as we do with the M-profile MPS3 FPGA images. In particular this means we will not model:
* USB controller
* graphical display or touchscreen
* QSPI flash (we will model it as simple ROM)
* GPIO controllers
* the Motherboard Configuration Controller
* the NIC-400 interconnect control interface (except possibly as a dummy implementation if necessary to get guest code running)

Required work

Unlike our existing MPS3 board models, this FPGA image is not M-profile and is not based on an ARMSSE-style SoC-like combination of CPU and devices. So the best approach will be to model it as an entirely separate board, without trying to share any code in the board model itself.

Most devices on the board we already have a model for:
* CMSDK UARTs
* CMSDK Dual-timer
* CMSDK Watchdog
* PL022 SPI controllers
* PL031 RTC
* SBCon I2C controllers
* LAN9220 Ethernet controller (as with existing MPS image models we will use our LAN9118 model, which is mostly software compatible)
* GICv3/v4 (there are no specific changes needed for Cortex-R52)

A few devices will likely need minor changes for this board:
* SCC (serial communication controller)
* FPGA IO regs

Notes

The real FPGA image does not have a global monitor that can support LDREX/STREX between the two CPUs for accesses in the DDR4 RAM or BRAM. This means that effectively guest software will only be able to use one CPU (the local monitor within the CPU works fine). This restriction won’t apply to the QEMU model, but is important to be aware of if you’re writing guest software on the QEMU model that you also want to be able to run on the FPGA board.