Qemu #515
Qemu #515
Conversation
Switch from CodeSourcery to ARM GCC and clean-up some stale files, also copy `main.c` and `mpconfigport.h` from bare-arm.
|
I'm thinking it'll be possible to add a FAT SD card image with the full test suite, passing it with |
|
So, does mainline qemu includes Cortex-M support now? I saw Cortex-M port somewhere, but it would be pleasant surprise to see it in mainline. Anyway, having some README for qemu port with basic info and instructions would help. |
|
This port looks very similar to |
|
Well, of course there are a few other changes, but I mean to say that is it necessary to have a separate port for something so similar to bare-arm? |
|
@dpgeorge true, it's very similar to the bare-arm. I was debating what to do, once I |
|
@pfalcon yes, it's been there for a while actually. It currently consists of 2 old |
|
Just in case, +1 from me, this is pure magic, and @errordeveloper's reasons for having this a separate port make sense (assuming he intends to work on it further). |
|
@pfalcon, surely I'd like to implement a way of running Regarding this pull-request, I don't intend to provide the implementations of test suite here, this is suppsed to make sense on it's own. I can update the top-level README to describe this port in general terms. There is in fact one important details, this was specifically tailored to ARM's version of GCC, and not the Mentor Graphics one. It turned out that linker scripts are quite a bit of a different story, which is something I attempted to note in the makefile already. |
|
Regarding the test-scripts, can't you just do it the way pyboard does? |
Sorry about that... I'm working on that problem right now! |
LOL, no rush. Just getting to grips with the unix port of uPy is keeping me busy enough ;-) |
This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
No description provided.