As an intro to my current side project, I’ve been attempting to run RTEMS on an emulated Microchip PolarFire system on mainline/upstream QEMU. I am not aware of a publicly available Microchip-specific QEMU branch that has additional/specific support. The build of QEMU that RTEMS Source Builder currently installs (5.2.0/5.1.91) is very near the original commit of the QEMU PolarFire support.
From what I can tell, this support hasn’t been touched beyond adding some peripherals and adding direct kernel boot (which seems to have stifled updates to the base functionality) since the support was initially added.
Direct kernel boot (DKB) support seems to be what is used primarily, but this is an issue for RTEMS in particular because DKB only supports boot in S-mode (supervisor-mode) whereas RTEMS only supports boot in M-mode (machine-mode). This means RTEMS must use the same mechanism to boot that it does on real hardware.
In booting as if on hardware, the user running QEMU must provide the hss.bin BIOS and a device image containing a GPT partition table with a specific configuration and the wrapped payload.bin as the raw contents of an appropriately marked partition. This presents two problems:
- Modern hss.bin does not appear to work with modern or historical QEMU
- The device image GPT header must have a specific header revision that I have not yet been able to replicate
The GPT header revision problem is easy enough to work around as examples are readily available that can have their contents replaced.
The hss.bin BIOS has multiple problems that must be addressed. Modern hss.bin binaries are meant to load at 0x20220100 wherease the original format supported by QEMU needs to load at 0x20220000. This is solved by rolling back to an older version from 2021, but this exposes other problems. The L2LIM memory space does not appear to be functioning correctly causing interesting problems. Relocating program sections away from L2LIM can make the older hss.bin more functional, but I have not yet been able to run it without moving some of those sections to ENVM and I don’t expect full functionality without moving other sections to DDR.