RFC: Emulation of MMIO devices for host-side testing

38 views
Skip to first unread message

Steve Barber

unread,
Jun 19, 2020, 8:37:03 PM6/19/20
to tock...@googlegroups.com
Hi tock-dev,

I've been working on adding register-based emulation of MMIO devices
to enable unit testing of drivers, and
would like to solicit feedback on the general design before dropping a
PR that might end up disrupting the
tock-registers crate and its users :)

The proposed implementation would avoid changing the tock-registers
interface for existing code, but would
allow a cargo feature to control the optional emulation feature. This
ensures no disruption for existing code in
drivers since the interface is identical, although Makefiles would
presumably need to be aware of toggling
the cargo feature during testing.

The more detailed design doc (with some alternative designs and
examples!) is available at
https://github.com/smibarber/tock/blob/mmio-emulation/doc/MMIO_Emulation.md
and proof-of-concept implementation at
https://github.com/smibarber/tock/blob/mmio-emulation/libraries/tock-register-interface/src/mmio_emu.rs

Thanks,
Steve

Branden Ghena

unread,
Jun 20, 2020, 2:43:02 PM6/20/20
to Steve Barber, Tock Embedded OS Development Discussion
Hi Steve,

I think the idea of being able to use the tock registers crate as is, and swap in emulation underneath it sounds great. One question I have for you is how would interrupts be triggered in this interface?

Thanks
Branden Ghena


--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/CADR9n480WxSfMOF4ovOaQh25%3DRA-RDKH0SMuHGZQp%2BOcEEKb1Q%40mail.gmail.com.

Steve Barber

unread,
Jul 2, 2020, 7:13:07 AM7/2/20
to Branden Ghena, Tock Embedded OS Development Discussion
Hi Branden,

Thanks for taking a look!

I haven't thought about handling interrupts in depth yet. I imagine simple tests could invoke a driver's interrupt handler directly, but that's not a very satisfying answer. I think a more robust solution would require an event loop so that an emulated device can't recurse infinitely (e.g. driver interrupt handler -> emulated device -> interrupt -> driver interrupt handler...).

Thanks,
Steve
Reply all
Reply to author
Forward
0 new messages