qemu-arm: Add license and copyright to files missing them.
All of these files are first-party code written from scratch as part of
this repository, and were added when the top-level MIT license was active,
so they have an MIT license by default. Tracing back the git history show
the original authors/source/copyright as follows:
- main.c, mpconfigport.h: copied from the bare-arm port [1].
- test_main.c: added in [2].
- mphalport.h: added in [3] then updated in [4].
- mps2.ld, nrf51.ld, stm32.ld, uart.h: added in [4].
- imx6.ld, uart.c, startup.c: added in [4] and updated in [5].
[1] Commit c55721582282f282d33e35e458a2944890210ebc in 2014, the initial
bare-arm port; see related ee857853d60a135685c5088e5492dfe6e8a5acb0.
[2] Commit c1c32d65af038ba1b2a2a8dd69e3f7e63eac5f3e in 2014, initial
qemu-arm CI tests.
[3] Commit b0a15aa73540f82ef47c9492af7ce196d1b1a6e9 in 2016, enabling
extmods and their tests.
[4] Commit e7332b05841549a41614e522285639dcaa7bd526 in 2018, big refactor.
[5] Commit b84406f3133a36a703a1506d754fc046dd955922 in 2021, adding
Cortex-A9 support.
Signed-off-by: Damien George <damien@micropython.org>
2024-06-11 12:13:37 +10:00
|
|
|
/*
|
|
|
|
|
* This file is part of the MicroPython project, http://micropython.org/
|
|
|
|
|
*
|
|
|
|
|
* The MIT License (MIT)
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2014 Ilya Dmitrichenko
|
|
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
|
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
|
* THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-02-16 17:23:06 +11:00
|
|
|
#include <stdlib.h>
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
#include <stdio.h>
|
|
|
|
|
|
2015-01-08 22:12:44 +00:00
|
|
|
#include "py/compile.h"
|
|
|
|
|
#include "py/runtime.h"
|
|
|
|
|
#include "py/stackctrl.h"
|
2015-01-12 12:07:42 +00:00
|
|
|
#include "py/gc.h"
|
2017-03-14 11:25:52 +11:00
|
|
|
#include "py/mperrno.h"
|
2021-07-09 14:19:15 +10:00
|
|
|
#include "shared/runtime/gchelper.h"
|
2019-12-17 13:18:08 +11:00
|
|
|
#include "lib/tinytest/tinytest.h"
|
|
|
|
|
#include "lib/tinytest/tinytest_macros.h"
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
|
2018-09-24 12:09:28 +10:00
|
|
|
#define HEAP_SIZE (100 * 1024)
|
2016-03-15 13:42:36 +00:00
|
|
|
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
#include "genhdr/tests.h"
|
|
|
|
|
|
|
|
|
|
int main() {
|
2016-01-29 01:05:53 +02:00
|
|
|
mp_stack_ctrl_init();
|
2015-01-08 22:12:44 +00:00
|
|
|
mp_stack_set_limit(10240);
|
2018-09-24 12:09:28 +10:00
|
|
|
static uint32_t heap[HEAP_SIZE / sizeof(uint32_t)];
|
2017-12-11 20:04:27 +02:00
|
|
|
upytest_set_heap(heap, (char *)heap + HEAP_SIZE);
|
2017-12-08 19:15:45 +02:00
|
|
|
int r = tinytest_main(0, NULL, groups);
|
|
|
|
|
printf("status: %d\n", r);
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void gc_collect(void) {
|
2015-01-12 12:07:42 +00:00
|
|
|
gc_collect_start();
|
2020-04-23 16:12:55 +10:00
|
|
|
gc_helper_collect_regs_and_stack();
|
2015-01-12 12:07:42 +00:00
|
|
|
gc_collect_end();
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
}
|
|
|
|
|
|
2023-09-27 13:43:50 +10:00
|
|
|
mp_lexer_t *mp_lexer_new_from_file(qstr filename) {
|
2017-03-14 11:25:52 +11:00
|
|
|
mp_raise_OSError(MP_ENOENT);
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void nlr_jump_fail(void *val) {
|
2017-02-16 17:23:06 +11:00
|
|
|
printf("uncaught NLR\n");
|
|
|
|
|
exit(1);
|
qemu-arm: fully integrated test suite.
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.
2014-05-05 17:06:45 +01:00
|
|
|
}
|