qemu support

[lu-zero]

Would be nice to support a system simulated by qemu and document how to bring it up.

[cbiffle]

I'm glad you asked! I'm working on a FAQ and QEMU is part of it.

QEMU's system-level emulation of the Cortex-M interrupt model, NVIC, SysTick, and other core components is not correct enough to usefully test Hubris. This has been the case for as long as I've been trying to use it for stuff like this (circa 2011) and we re-tested this past spring and it's still true. Hubris might run under QEMU, but test results wouldn't reflect actual hardware, making it less useful for us. (If I recall correctly we did experience random hangs on QEMU; your mileage may vary.)

We've considered trying to fix it, but it doesn't look easy, and we are a small team focused on getting our product ready.

[cbiffle]

@bcantrill has reminded me that we've actually got a repo with one of the QEMU bug cases we hit. https://github.com/oxidecomputer/qemu-systick-bug

[lu-zero]

Hopefully the current qemu might be less buggy, if you have already some guide to test it I can try to give it a go and report back :)

[mx-shift]

https://xpack.github.io/qemu-arm/ claims to emulate STM32F4 Discovery. Hubris supports that board via app/demo-stm32f4-discovery/app.toml. Let us know how it goes.

[lu-zero]

I tried to do the following:

xpack-qemu-arm-2.8.0-13/bin/qemu-system-gnuarmeclipse -board STM32F4-Discovery --image /Users/lu_zero/Sources/rust/hubris/target/thumbv7em-none-eabihf/release/demo-stm32f4-discovery
qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.

And after that it seems hanging, having some step-by-step instructions would be nice to have ^^;

[mx-shift]

As we said before, our experience is that qemu's Cortex-M models are inaccurate enough that we don't use qemu with Hubris at Oxide. We don't have any step-by-step instructions because we don't know and it's not a path that we intend to spend any time investigating.

As for the error message you got, Hubris assumes the device has hardware floating point. Qemu's model apparently doesn't implement it. You'd need to add floating point support to qemu's model as stm32f4 discovery has floating point.

On Mon, Dec 6, 2021, 2:27 AM Luca Barbato @.***> wrote:

I tried to do the following:

xpack-qemu-arm-2.8.0-13/bin/qemu-system-gnuarmeclipse -board STM32F4-Discovery --image /Users/lu_zero/Sources/rust/hubris/target/thumbv7em-none-eabihf/release/demo-stm32f4-discovery qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.

And after that it seems hanging, having some step-by-step instructions would be nice to have ^^;

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/oxidecomputer/hubris/issues/284#issuecomment-986641554, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIEHF73ERXQ7OIK5YZ7PGLUPSFXTANCNFSM5JGYQT3A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[cbiffle]

It's surprising that they would claim support for STM32F4 if they don't have floating point turned on. I would expect most programs written for STM32F4 these days are built with floating point support.

[shua]

The open ticket listed in https://github.com/oxidecomputer/qemu-systick-bug for the arm systick issue https://bugs.launchpad.net/qemu/+bug/1872237 has been closed as fixed. I imagine plenty more still outstanding, but figured I'd update this ticket.