From dbfec89e031371bae414faf426139ac551396582 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Sun, 26 May 2019 00:00:00 +0000 Subject: [PATCH] baremetal: fix getting started after userland unification --- README.adoc | 73 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 41 insertions(+), 32 deletions(-) diff --git a/README.adoc b/README.adoc index 5ad6358..79b8313 100644 --- a/README.adoc +++ b/README.adoc @@ -755,7 +755,7 @@ Or to run a baremetal example instead: .... ./run \ --arch aarch64 \ - --baremetal baremetal/c/hello.c \ + --baremetal userland/c/hello.c \ --qemu-which host \ ; .... @@ -1193,37 +1193,48 @@ Our C bare-metal compiler is built with link:https://github.com/crosstool-ng/cro Every `.c` file inside link:baremetal/[] and `.S` file inside `baremetal/arch//` generates a separate baremetal image. -For example, to run link:baremetal/c/hello.c[] in QEMU do: +For example, to run link:baremetal/arch/aarch64/dump_regs.c[] in QEMU do: .... ./build --arch aarch64 --download-dependencies qemu-baremetal -./run --arch aarch64 --baremetal baremetal/c/hello.c +./run --arch aarch64 --baremetal baremetal/arch/aarch64/dump_regs.c .... -The terminal prints: +And the terminal prints the values of certain system registers. This example prints registers that are only accessible from <> or higher, and thus could not be run in userland. + +In addition to the examples under link:baremetal/[], several of the <> can also be run in baremetal! This is largely due to the <>. + +The examples that work include most <> that don't rely on complicated syscalls such as threads, and almost all the <> examples. + +The exact list of userland programs that work in baremetal is specified in <> with the `baremetal` property, but you can also easily find it out with a <>: .... -hello +./test-baremetal --arch aarch64 --dry-run +.... + +For example, we can run the C hello world link:userland/c/hello.c[] simply as: + +.... +./run --arch aarch64 --baremetal userland/c/hello.c .... To modify a baremetal program, simply edit the file, e.g. .... -vim baremetal/c/hello.c +vim userland/c/hello.c .... and rebuild: .... ./build-baremetal --arch aarch64 -./run --arch aarch64 --baremetal baremetal/c/hello.c +./run --arch aarch64 --baremetal userland/c/hello.c .... `./build qemu-baremetal` that we run previously is only needed for the initial build. That script calls link:build-baremetal[] for us, in addition to building prerequisites such as QEMU and crosstool-NG. `./build-baremetal` uses crosstool-NG, and so it must be preceded by link:build-crosstool-ng[], which `./build qemu-baremetal` also calls. - Now let's run link:baremetal/arch/aarch64/add.S[]: .... @@ -1251,12 +1262,6 @@ and the exit status of our script is 1: echo $? .... -As suggested by the above example, several of the <> can also be run in baremetal! This is largely due to the <>. - -The examples that work include most <> that don't rely on complicated syscalls such as threads, and almost all the <> examples. - -The exact list of userland programs that work in baremetal is specified in <> with the `baremetal` property. - You can run all the baremetal examples in one go and check that all assertions passed with: .... @@ -1267,7 +1272,7 @@ To use gem5 instead of QEMU do: .... ./build --download-dependencies gem5-baremetal -./run --arch aarch64 --baremetal baremetal/c/hello.c --emulator gem5 +./run --arch aarch64 --baremetal userland/c/hello.c --emulator gem5 .... and then <> open a shell with: @@ -1279,7 +1284,7 @@ and then <> open a shell with: Or as usual, <> users can do both in one go with: .... -./run --arch aarch64 --baremetal baremetal/c/hello.c --emulator gem5 --tmux +./run --arch aarch64 --baremetal userland/c/hello.c --emulator gem5 --tmux .... TODO: the carriage returns are a bit different than in QEMU, see: <>. @@ -1287,8 +1292,8 @@ TODO: the carriage returns are a bit different than in QEMU, see: <>, do everything in one go with: .... -./run --arch arm --baremetal baremetal/c/hello.c --gdb +./run --arch arm --baremetal userland/c/hello.c --gdb .... Alternatively, to start from the very first executed instruction of our tiny <>: @@ -13080,13 +13087,13 @@ Alternatively, to start from the very first executed instruction of our tiny </no_bootloader/*.S`, e.g.: @@ -13223,7 +13230,7 @@ For `arm`, some baremetal examples compile fine with: .... sudo apt-get install gcc-arm-none-eabi qemu-system-arm ./build-baremetal --arch arm --gcc-which host-baremetal -./run --arch arm --baremetal baremetal/c/hello.c --qemu-which host +./run --arch arm --baremetal userland/c/hello.c --qemu-which host .... However, there are as usual limitations to using prebuilts: @@ -13294,7 +13301,7 @@ TODO: any advantage over QEMU? I doubt it, mostly using it as as toy for now: Without running `./run`, do directly: .... -./run-gdb --arch arm --baremetal baremetal/c/hello.c --sim +./run-gdb --arch arm --baremetal userland/c/hello.c --sim .... Then inside GDB: @@ -13874,12 +13881,12 @@ Source: link:test-baremetal[] Analogously to <>, we can select individual tests or directories with: .... -./test-baremetal --arch aarch64 baremetal/c/hello.c baremetal/arch/aarch64/no_bootloader/ +./test-baremetal --arch aarch64 userland/c/hello.c baremetal/arch/aarch64/no_bootloader/ .... which would run all of: -* link:baremetal/c/hello.c[] +* link:userland/c/hello.c[] * all tests under the directory: link:baremetal/arch/aarch64/no_bootloader/[] We detect if tests failed by parsing logs for the <>. @@ -15171,7 +15178,7 @@ The link:test[] script runs several different types of tests, which can also be * <> * <> * <> -* <> +* <> * <> link:test[] does not all possible tests, because there are too many possible variations and that would take forever. The rationale is the same as for `./build all` and is explained in `./build --help`. @@ -15234,7 +15241,7 @@ Failure is detected by looking for the <> Most userland programs that don't rely on kernel modules can also be tested in user mode simulation as explained at: <>. -===== Test GDB +===== GDB tests We have some link:https://github.com/pexpect/pexpect[pexpect] automated tests for the baremetal programs! @@ -15247,6 +15254,8 @@ Sources: * link:build-test-gdb[] * link:test-gdb[] +* link:userland/arch/arm/gdb_tests/[] +* link:userland/arch/aarch64/gdb_tests/[] If a test fails, re-run the test commands manually and use `--verbose` to understand what happened: