bug report? Is it considered a bug when a stm32f4 based open-source software can't boot in renode?

[davidbuzz]

Description

this software/firmware, which runs almost entirely in STM32F4 and higher, and doesn't run under renode:
https://github.com/ArduPilot/ardupilot
ready-to-use binaries available here: https://firmware.ardupilot.org/
custom on-demand binaries can also be built here: https://custom.ardupilot.org/
It runs [almost entirely] on "chibios" as its RTOS, and has a very long list of supported-out-of-the-box STM32 hardware defined here:
https://github.com/ArduPilot/ardupilot/tree/master/libraries/AP_HAL_ChibiOS/hwdef

Expected behaviour

It would be a game-changer the the entire ardupilot/drone community if all/some of the boards it supports could be simulated at the hardware layer, running the same binary.

How to reproduce?

Using one of the popular 'ardupilot' board/s called 'CubeBlack' as an example:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ChibiOS/hwdef/CubeBlack/README.md

This is stm32f4 / STM32F427 , so we can get a binary, eg here:
https://firmware.ardupilot.org/Copter/stable/CubeBlack/
You can also compile it yourself to enable --debug flags, which i did.. https://ardupilot.org/dev/index.html is the "dev" guide that has all the git clone and whatnot but it ends with.. ./waf configure --board=CubeBlack --debug ; ./waf copter

how to reproduce the issue:

I made a fork, and put the binary, startup script, gdbinit here:
https://github.com/davidbuzz/renode/tree/ardu-cubeblack-stm32f4-wip
clone my repo, build it the usual way then run:
./renode cubeblack.resc
[ the full output of this command is provided in my repo above as "boot.log" ]

it clearly boots a long way into the ArduPilot code, as I see a lot of function calls starting with "AP_", and theres a bunch of chibios calls in there too... search log for ChibiOS or ' ch'...

Aparently chibios does a few things on boot, such as waiting for the RCC to stabilise that might not be implemented in emulator?

ardupilot/chibios also uses an external oscillator in most of its default setup/s , although that can be turned off in a built-it-yourself if needed.

ardupilot aparently runs chibios in "tickless" mode, I'm not the expert on that ,but relying on timers for scheduling might also be related.?

I dont understand your test infrastructure yet, so couldn't set it up as "real test".

[ I tried building arducopter so it uses the internal oscilator instead of the external one, and provide a .no-oscillator-test. binary variant, but it seems to behave similar-enough to the other one. ]

Environment.

Please, provide the following information:

• OS

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=23.10
DISTRIB_CODENAME=mantic
DISTRIB_DESCRIPTION="Ubuntu 23.10"

• Renode version (with commit SHA)

 ./renode -v
Renode v1.15.0.17335
  build: ea413fae-202405060937
  build type: Release
  runtime: Mono 4.0.30319.42000

Do you plan to address this issue and file a PR?

I dont have adequate knowledge/skills to address this myself.

[davidbuzz]

Oh, the binaries in the above repo have debug symbols. the one/s available for general download probably dont.

I also tried with/without the content of this PR as its related to a F4 peripheral, and I couldn't see any difference:
#601

[davidbuzz]

I've also [ as a second commit ], added a 1000x simplified binary that just demonstrates starting the the ArduPilot HAL (ontop of chibios ) , and printing out all the uarts.... and this doesn't work either..

run the simlified test like this:
./renode cubeblack.UART_test.resc

src here:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL/examples/UART_test/UART_test.cpp

how to build [ArduPilot/ArduPilot]
./waf configure --board=CubeBlack --debug
./waf build --target examples/UART_test

... also over in https://github.com/davidbuzz/renode/tree/ardu-cubeblack-stm32f4-wip