davidspickett / badgerkernel Goto Github PK

Hi,

I try to build the files using another cross compiler aarch64-none-elf-gcc from GNU Toolchain | GNU-A Downloads - Arm Developer

The environment is:

QEMU emulator version 5.1.0
aarch64-none-elf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025

I run this command to replace the compiler prefix

$ sed -i 's/aarch64-elf-/aarch64-none-elf-/' CMakeLists.txt

The error mesage of make turns out to be

$ make

<...>

[  4%] Built target shell
[  5%] Built target echo
[  9%] Built target fibres
[  9%] Built target test_fibres
[ 12%] Built target signalhandling
[ 16%] Built target trace
[ 16%] Built target test_trace
[ 20%] Built target parentchild
[ 20%] Built target test_parentchild
[ 24%] Built target loadpiebinary
[ 24%] Linking C executable piebinary
/home/oscar/utils/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin/../lib/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/bin/ld: CMakeFiles/piebinary.dir/demos/loadpiebinary/piebinary.c.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC
CMakeFiles/piebinary.dir/demos/loadpiebinary/piebinary.c.o: in function `add_foo_thread':
/tmp/ARMMultiTasking/demos/loadpiebinary/piebinary.c:26:(.text+0x8c): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/piebinary.dir/build.make:84: piebinary] Error 1
make[1]: *** [CMakeFiles/Makefile2:645: CMakeFiles/piebinary.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

Maybe we should add -fPIC into compiler arguments in this case?

Describe the bug
The shell demo fails to open stdin to read the input from terminal.

Configuration

• cmake version (cmake --version)

cmake version 3.16.3

• toolchain/compiler version (gcc --version, for example)

aarch64-none-elf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

• QEMU version (qemu-system-arm --version)

QEMU emulator version 5.1.0
QEMU emulator version 4.2.1

To Reproduce (complete those that apply):

• cmake configuration

cmake . -DBUILD_PLATFORM=arm
cmake . -DBUILD_PLATFORM=aarch64
cmake . -DBUILD_PLATFORM=thumb

• make command

make

• run command

make run_shell

Expected behavior

The shell demo should work properly.

Affected platforms/settings
List any other settings/platforms/software versions you have tried and whether that had any effect.
e.g. "This issue presents at -O2 but not -O1."

This problem occurs all platflaform listed below

• arm
• aarch64
• thumb

The error output is like this:

$ make run_shell
[ 57%] Built target shell
[ 71%] Built target ps
[ 85%] Built target echo
[100%] Built target ls
---------------------
----- AMT Shell -----
---------------------
$ /home/oscar/ARMMultiTasking/demos/shell/shell.c:236 (command_loop) Expected: (got != 0) && "stdin closed!"
make[3]: *** [CMakeFiles/run_shell.dir/build.make:57: run_shell] Error 1
make[2]: *** [CMakeFiles/Makefile2:894: CMakeFiles/run_shell.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:901: CMakeFiles/run_shell.dir/rule] Error 2
make: *** [Makefile:430: run_shell] Error 2

The problem may occurs in both version mentioned above, but in QEMU 2.11.2, the shell demo works properly.
And I try to checkout to some previous commit, but it ends up to have some problems when I try to enter something

$ make run_shell
[ 57%] Built target shell
[ 71%] Built target ps
[ 85%] Built target echo
[100%] Built target ls
---------------------
----- AMT Shell -----
---------------------
$ d?�Um?�Uf?�UUnhandled escape sequence!
make[3]: *** [CMakeFiles/run_shell.dir/build.make:57: run_shell] Error 1
make[2]: *** [CMakeFiles/Makefile2:894: CMakeFiles/run_shell.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:901: CMakeFiles/run_shell.dir/rule] Error 2
make: *** [Makefile:430: run_shell] Error 2

It seems that QEMU had disabled some settings which is used to be turned on in 2.* versions but I fail to find the proper setting of it.

Is there any clue to find or fix it?

It is very clear and easy to understand what happens in each of the demos.

But I am wondering if the system becomes more complex, maybe it is hard to use the log to ensure the system works properly. (eg: the executing order of each process or the time quantum each process can use)

Is that any tool in AMT that can verify the behaviour of the system? (such as the order of executing, the time quantum each process gets, ...)

Hello,

I just have encounter some problems while compiling this repository.

Here is the tool chain I used and the version of them

$ cat /etc/os-release | head -6
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"

$ aarch64-elf-gcc --version | head -1
aarch64-elf-gcc (Linaro GCC 7.5-2019.12) 7.5.0

$ qemu-system-arm --version | head -1
QEMU emulator version 5.1.0

aarcdh64-elf-gcc is from Linaro Releases
qemu 5.1 is from Download QEMU - QEMU

And this is the error message when I execute make command

$ make

(skip)

[  9%] Building C object CMakeFiles/fibres.dir/src/user/timer.c.o
[  9%] Building C object CMakeFiles/fibres.dir/src/user/fibre.c.o
[  9%] Building C object CMakeFiles/fibres.dir/src/hw/arm_common/gic.c.o
[  9%] Linking C executable fibres
aarch64-elf-gcc (Linaro GCC 7.5-2019.12) 7.5.0
[  9%] Built target fibres
Scanning dependencies of target test_fibres
make[2]: *** [CMakeFiles/test_fibres.dir/build.make:57: test_fibres] Error 1
make[1]: *** [CMakeFiles/Makefile2:321: CMakeFiles/test_fibres.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

I try to execute the command in CMakeFiles/test_fibres.dir/build.make:57, and I got this error:

$ qemu-system-aarch64 -M virt -cpu cortex-a57 -m 1M -nographic -semihosting -kernel fibres -serial file:fibres_got.log
QEMU 5.1 monitor - type 'help' for more information
(qemu) rom: requested regions overlap (rom dtb. free=0x0000000000007d30, addr=0x0000000000000000)
qemu-system-aarch64: rom check and register reset failed

Describe the bug
The shell demo freezes at the beginning and fails to run. Other demos finish without any output.

Configuration:

• cmake version (cmake --version)

cmake version 3.16.3

• toolchain/compiler version (gcc --version, for example)

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

aarch64-none-elf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025

• QEMU version (qemu-system-arm --version)

QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.8)

To Reproduce:

• cmake configuration

-- BUILD_PLATFORM is arm
-- OPT_LEVEL is -O0
-- SANITIZERS are ON
-- LTO is OFF
-- COVERAGE is 
-- STACK_SIZE is 2KB
-- ccache is enabled
-- Configuring done
-- Generating done
-- Build files have been written to: /home/oscar/ARMMultiTasking

• make command

make

• run command

make run_shell

Expected behavior
The demos will print out some log messages or let us to type something.

Affected platforms/settings
It occurs on all platforms:

• arm
• thumb
• aarch64

Additional context
I think that it is a problem when using QEMU 4.2.1, since it successfully runs on QEMU 5.1.0.

I use git checkout to some previous commit. It seems that the problem occurs after b089ef2.

I try to use gdb to locate the error, but it turns out the shell demo works properly when I execute the code one by one.
So I am not sure where the error is.

Hi,

I am currently trying to call memset to initialize bss section on my raspi4, but found out the board halted as a result.

After digging into the implementation of memset, I realized that the alignment fault occurred when calling this function.

According to Armv8-A architecture profile, when stage 1 address translation is disabled, the memory will be defined as device type (in D5.2.9 section).
However, any unaligned access to device type memory will cause an alignment fault and halt the board (in B2.5.2 section).

In current stage, AMT does not enable MMU. Any unaligned access to the memory may cause this fault and freeze the kernel.

Is there any idea to overcome this problem? Or we should turn on the setting for MMU?