cederom commented on issue #15733: URL: https://github.com/apache/nuttx/issues/15733#issuecomment-2628031130
Copy-Paste from https://github.com/apache/nuttx/issues/15730 for context :-) > > [@fdcavalcanti](https://github.com/fdcavalcanti): [@cederom](https://github.com/cederom) there are plenty of QEMU tests on Espressif side, all pytest based. If there is computing power available for running more QEMU tests, we could think of a way to integrate those tests to Nuttx. Had a brief talk about this with [@lupyuen](https://github.com/lupyuen), so I'm tagging him here. > > @cederom: Thank you [@fdcavalcanti](https://github.com/fdcavalcanti) that would be great!! > > Ultimately DRUNX will work on home computers of interested users, [@lupyuen](https://github.com/lupyuen) already has working prototype that simply run the CI scripts that we run on GitHub. There is also Dashboard that sums up the builds from various places. Ultimately there will be as many computing powers as tehere are users testing :-) > > PyTest is a well standardized choice :-) > > Are those QEMU images available to fetch from some public repo or even build by hand? > > What platforms are supported? > > Do you have some sort of bootstrap for them? > > ESP QEMU tests would perfectly fit the build and runtime in a situation where no hardware is available or necessary.. maybe even GH CI if not too expensive to run :-) > > How much place would it take to place them in `nuttx-apps/testing`? > > I have created dedicated issue here: [#15733](https://github.com/apache/nuttx/issues/15733) :-) > > Thank you!! :-) @fdcavalcanti: We use QEMU available for ESP32, ESP32S3 and ESP32C3. You can find them [here](https://github.com/espressif/qemu). All tests are Pytest based, but heavily use the [pytest-embeded](https://github.com/espressif/pytest-embedded) plugin, more specifically the pytest-embedded-nuttx plugin (supports Nuttshell parsing, flashing, etc). Simple tests like building, booting and testing if nsh> is responsive exist. Which is enough to know if the build is at least working to this extent. This allows testing most defconfigs that do not require external hardware, WiFi and BLE. We also test bootloader combinations: reuse all defconfigs and apply MCUBoot instead of simple boot. However there are more complex tests that use some customized application similar to nuttx-apps. Most would be Espressif related since they target our boards and don't follow some rules (like directly calling GPIO instead of using gpio.h when testing motor driver, capture driver, etc). That's something to be analyzed internally first. I'm afraid the current NuttX CI image is not compatible. We use a Docker image that has the build system and all plugins required for the tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
