idk-development-kit / idk

0 stars 0 forks source link

Emulate hardware peripherals #30

Open backup-isaac opened 4 years ago

m5w commented 4 years ago

My primary concern with this is verification. How will we know that the code we've written accurately emulates Tiva peripherals (oh, and the TM4C123x and TM4C129x have different peripherals, and the TM4C129x might even have different peripherals between different parts), including silicon errata? We would need to do a lot of low-level hardware testing, potentially including fuzzing. This could be its own project (not a GitHub project, but an entirely separate open-source project).

Although, we might just have different ideas about the level of detail of such emulation. @backup-isaac, what is your vision for this?

backup-isaac commented 4 years ago

I'm not sure exactly how this is implemented, but I've been able to connect stdin / stdout to the UART of a device emulated in qemu-system-aarch64. The emulated kernel was using UART and GPIO drivers I wrote, so I imagine the peripheral is being emulated at the register level. I'm not sure how much you'd have to account for silicon errata and hardware specific behavior, although this is supported at least in limited capacity by other emulated devices in QEMU so it might be worth looking at how they implement and verify it. There may also be ways in which we can get away with emulation not being perfect; for instance qemu-system-aarch64 implements the wfe (wait for event in a low power state) instruction as a no-op.

It might also be possible, although more limiting, to emulate peripherals at the level of e.g. driverlib, although that may not actually do much to solve the complexity.

What I had in mind is that, for instance, you could send an emulated device's I/O ports data from stdin (or a file descriptor) to test how the device interacts with that I/O.