Tock: [QEMU] Is there a plan to support "The xPack QEMU Arm"?

[dpinthinker]

As hardware boards are always hard to get, is there a way to support more QEMU boards?

I just found that "The xPack QEMU Arm" has supported one dozen ARM mcu and boards. It will be very convenient for the developers if "The xPack QEMU Arm supported boards" are supported by Tock OS.

Really hope these QEMU boards can be supported.

Thanks!

[bradjc]

That looks very interesting. We have just recently started adding QEMU to various Tock workflows, but so far only with RISC-V based boards. Having QEMU support for STM32 cores would both make it easier to get started with Tock while also help us test for STM32 cores.

Is this something you would be interested in looking into? We would definitely be interested in using something along these lines.

[alistair23]

There is a growing push to run Tock on QEMU. From the RISC-V perspective I am aiming to use QEMU for automated RISC-V testing, so it should have decent support.

For the ARM boards I suggest using mainline QEMU (instead of other forks). I am happy to help get ARM Tock running on mainline QEMU. The work done should benefit everyone instead of specific forked versions of QEMU, that are susceptible to disappearing or other issues.

I am the QEMU STM32 maintainer (QEMU supports more then just large boards), so that seems like a good place to start now that Tock has STM32 support.

[dpinthinker]

It's great! Looking forward to the Tock on QEMU STM32!

@bradjc Yes, this is just what we are looking for. The STM32 QEMU support would help a lot to simply debug works for developers. For example, the android emulator helps a lot to the android system and application developers.

@alistair23 Mainline QEMU is fine. I just found that the xPack QEMU arm seems support more boards now.

One more question, is there a roadmap for the QEMU STM32 supporting?

[alistair23]

Just to clarify. My primary focus is RISC-V, so I probably won't look into running Tock on QEMU ARM myself.

I more meant I am happy to help someone else get it working.

I know QEMU supports the STM32F205 and STM32F405 with the Netduino 2 and Netduino 2 Plus board, while Tock supports the STM32F303 on the discovery board.

I have no idea what the difference is between the two SoCs. A really quick look at the datasheets indicates that they have different memory mappings, so some work would be required. If the devices (USART, SYSCFG, etc.) are otherwise the same (or similar) it would be very easy to port to a new board in QEMU.

I suspect it wouldn't be too hard to do, it would just need someone with a little bit of time to look at.

[alistair23]

This is the problem with replying late at night :)

Tock has an STM32Fxx board (the NUCLEO-F429ZI) so that should work. I tried it but it starts execution at 0 which causes a fault.

Does Tock expect a boot loader to jump to some address?

[rajivr]

Tock has an STM32Fxx board (the NUCLEO-F429ZI) so that should work. I tried it but it starts execution at 0 which causes a fault.

I think execution at 0x0000_0000 and reading first two words - one for MSP and another for reset vector is an ARMv7-M specific convention. MCU vendors typically provide some way to disable this behavior. In case of STM32F446RE, there is something known as BOOT0 and BOOT1 pins. When BOOT0 is pulled low, the main flash area is selected. That would correspond to rom memory area. So, the first word from rom is used as MSP and second word would correspond to the reset vector. This is indicated in the BASE_VECTORS

[alistair23]

Thanks.

I got it to run. I just had to compile the Tock binary to start at 0 instead of 0x800_0000 due to a known QEMU bug with the flash alias and reset.

I can run the nucleo_f429zi Tock binary on QEMU. It boots all the way to the kernel_loop() function based on the assembly output from QEMU.

It looks like the simple STM USART device in QEMU is missing some functionality that Tock expects so prints aren't working. I'll have to dig into that a bit more but shouldn't be too hard.

Hopefully that should be enough to get it running on QEMU.

[dpinthinker]

Thanks.

I got it to run. I just had to compile the Tock binary to start at 0 instead of 0x800_0000 due to a known QEMU bug with the flash alias and reset.

I can run the nucleo_f429zi Tock binary on QEMU. It boots all the way to the kernel_loop() function based on the assembly output from QEMU.

It looks like the simple STM USART device in QEMU is missing some functionality that Tock expects so prints aren't working. I'll have to dig into that a bit more but shouldn't be too hard.

Hopefully that should be enough to get it running on QEMU.

@alistair23 Thank you so much! Looking forward to your next good news.

[ppannuto]

A quick note regarding bootloaders: Tock does have one if needed: https://github.com/tock/tock-bootloader/ (it's a stripped down version of the Tock kernel itself). More useful for physical hardware, as a convenient mechanism for flashing apps

[dpinthinker]

Thanks.

I got it to run. I just had to compile the Tock binary to start at 0 instead of 0x800_0000 due to a known QEMU bug with the flash alias and reset.

I can run the nucleo_f429zi Tock binary on QEMU. It boots all the way to the kernel_loop() function based on the assembly output from QEMU.

It looks like the simple STM USART device in QEMU is missing some functionality that Tock expects so prints aren't working. I'll have to dig into that a bit more but shouldn't be too hard.

Hopefully that should be enough to get it running on QEMU.

@alistair23 Hi Alistair, I don't mean to rush you. Is there anything I can help? I would like to help if possible.

[alistair23]

So I dug into this a bit more.

There are two main issues:

1. The QEMU reset ordering bug. This means the v7M CPUs don't correctly set the registers on reset from the flash alias. This can be fixed for QEMU by building Tock at address 0. This is a known QEMU bug and hopefully will be fixed eventually.
2. Once Tock is built at address 0 it correctly runs. The next problem is that QEMU doesn't model the STM32Fxx DMA device. Tock uses this DMA for the USART so there are no prints without the DMA device. Someone will need to write a model of this.

[alistair23]

I have created a general tracking issue: https://github.com/tock/tock/issues/1827 for QEMU support overall.

[alistair23]

I'm going to close this issue as it's tracked by #1827