d9a0fdda9a
Currently, the qemu-arm (and qemu-riscv) port has two build modes:
- a simple test that executes a Python string; and
- a full test that uses tinytest to embed all tests within the firmware,
then executes that and captures the output.
This is very different to all the other ports. A difficulty with using
tinytest is that with the large number of tests the firmware overflows its
virtual flash size. It's also hard to run tests via .mpy files and with
the native emitter. Being different to the other ports also means an extra
burden on maintenance.
This commit reworks the qemu-arm port so that it has a single build target
that creates a standard firmware which has a REPL. When run under
qemu-system-arm, the REPL acts like any other bare-metal port, complete
with soft reset (use machine.reset() to turn it off and exit
qemu-system-arm).
This approach gives many benefits:
- allows playing with a REPL without hardware;
- allows running the test suite as it would on a bare-metal board, by
making qemu-system-arm redirect the UART serial of the virtual device to
a /dev/pts/xx file, and then running run-tests.py against that serial
device;
- skipping tests is now done via the logic in `run-tests.py` and no longer
needs multiple places to define which tests to skip
(`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also
`tests/run-tests.py`);
- allows testing/using mpremote with the qemu-arm port.
Eventually the qemu-riscv port would have a similar change.
Prior to this commit the test results were:
743 tests ok. (121 skipped)
With this commit the test results are:
753 tests performed (22673 individual testcases)
753 tests passed
138 tests skipped
More tests are skipped because more are included in the run. But overall
more tests pass.
Signed-off-by: Damien George <damien@micropython.org>
MicroPython port to qemu-arm
This is experimental, community-supported port for Cortex-M emulation as provided by QEMU (http://qemu.org).
The purposes of this port are to enable:
- Continuous integration
- run tests against architecture-specific parts of code base
- Experimentation
- simulation & prototyping of anything that has architecture-specific code
- exploring instruction set in terms of optimising some part of MicroPython or a module
- Streamlined debugging
- no need for JTAG or even an MCU chip itself
- no need to use OpenOCD or anything else that might slow down the process in terms of plugging things together, pressing buttons, etc.
Build instructions
First make sure the MicroPython cross-compiler is built (run from this directory):
$ make -C ../../mpy-cross
Then build using:
$ make
The default qemu-supported board is mps2-an385, a Cortex-M3 board. To select a
different board pass the BOARD argument to make, for example:
$ make BOARD=sabrelite
Running
When the firmware is run it will provide a REPL on the emulated hardware UART. To access the REPL directly use:
$ make repl
This will start qemu-system-arm with the UART redirected to stdio. It's also
possible to redirect the UART to a pty device using:
$ make run
This will start the emulation and the name of the pty device will be printed to
stdout. This serial device then be accessed via a serial terminal program,
for example mpremote:
$ mpremote connect /dev/pts/1
You can disconnect and reconnect to the serial device multiple times. Once you
are finished, stop the make run command by pressing Ctrl-C where that command
was started (or execute machine.reset() at the REPL).
The test suite can be run against the firmware by using the UART redirection. You can either do this automatically using the single command:
$ make test
Or manually by first starting the emulation with make run and then running the
tests against the serial device, for example:
$ cd ../../tests
$ ./run-tests.py --target qemu-arm --device /dev/pts/1