search

CTSRD-CHERI / qemu

QEMU with support for CHERI
Other
52 stars 28 forks source link

Add GICv3 and UARTs to the morello board #229

Open damaki opened 1 year ago

damaki commented 1 year ago

This adds support for the interrupt controller (GICv3) and the three PL011 UARTs on the emulated morello board. The purpose is to improve the emulation for bare-metal applications running on the morello board which use interrupts (e.g. timers) and UART communications.

The configuration of the GICv3 and UARTs is based on the code in the "virt" machine (hw/arm/virt.c).

jrtc27 commented 1 year ago

If you need the morello board you probably should be using the FVP, otherwise you should be using the virt board. It exists solely to be able to run the conformance tests. Our goal for Morello QEMU is purely ISA emulation, not also peripherals.

arichardson commented 1 year ago

I think it's useful to have both a "Morello ISA" model (board=virt?) and a model that mostly approximates the real hardware. Obviously we won't emulate everything (GPU/Network/etc.) but if it's this simple to add some of the other peripherals I don't see why not?

damaki commented 1 year ago

Thanks for the feedback!

Our testing infrastructure is based around QEMU, and the FVP is unfortunately too heavy for our needs.

The virt board is unsuitable for our purposes since we're targeting a bare-metal environment and need something a bit more representative of the Morello board to run our bare-metal Ada language conformance tests. The only peripherals we need to support our bare-metal conformance tests are the interrupt controller (GICv3) and UART, and it was quite simple to add support for them.

arichardson commented 1 year ago

I don't think this does any harm, so I'd be happy to merge it (assuming the addresses are correct - not managed to check that). I do agree that the virt board is probably better to be used in most cases.

jrtc27 commented 1 year ago

My concern is feature creep for something that was never meant to be used in any situation other than running the compliance tests. I don't think we want to be supporting people actually using it outside of that? It should probably have been named morello-ack from the start. After all, it's got a (cut-down) trickbox in there that doesn't exist in the real hardware.

arichardson commented 1 year ago

My concern is feature creep for something that was never meant to be used in any situation other than running the compliance tests. I don't think we want to be supporting people actually using it outside of that? It should probably have been named morello-ack from the start. After all, it's got a (cut-down) trickbox in there that doesn't exist in the real hardware.

That's a good point (although the trickbox is not there by default if I read the code correctly). I am a bit conflicted here, but I think having the Morello machine type more closely match HW is a good thing. That said, ideally your OS/baremetal application should try to discover the addresses of peripherals instead of relying on hardocded values.