Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Cannot execute applications for big core (RVV1.0) compiled with non-vendor toolchain (e.g. GCC 13.2.0) #9

Open
pfalz-benni opened this issue Jul 21, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@pfalz-benni
Copy link

pfalz-benni commented Jul 21, 2024

What happened

Due to its improvements in vectorization, I want to use a newer version of the GCC toolchain to build applications for the big core that implements RVV1.0. I am able to build the executable with the standard RISC-V GCC 13.2.0 (rv64gc_lp64d_linux_musl_medany), also linking the provided liker script (https://github.com/kendryte/k230_sdk/blob/main/src/big/rt-smart/userapps/linker_scripts/riscv64/link.lds).

When I execute the elf file (a simple main function returning 0) on the big core I get the following error:

[E/DBG] [FATAL ERROR] Exception 13:Load Page Fault
[E/DBG] scause:0x000000000000000d,stval:0x000000000151ccb8,sepc:0x0000000200000014
--------------Dump Registers-----------------
Function Registers:
        ra(x1) = 0x00000000003435ee()
        user_sp(x2) = 0x000000000151ccb0()
        gp(x3) = 0x0000000000000000()
        tp(x4) = 0x00000000deadbeef()
Temporary Registers:
        t0(x5) = 0x0000000000000020()
        t1(x6) = 0x00000000deadbeef()
        t2(x7) = 0x00000000deadbeef()
        t3(x28) = 0x00000000deadbeef()
        t4(x29) = 0x00000000deadbeef()
        t5(x30) = 0x00000000deadbeef()
        t6(x31) = 0x00000000deadbeef()
Saved Registers:
        s0/fp(x8) = 0x00000000014bbc72()
        s1(x9) = 0x00000000014bb342()
        s2(x18) = 0x00000000deadbeef()
        s3(x19) = 0x00000000deadbeef()
        s4(x20) = 0x00000000deadbeef()
        s5(x21) = 0x00000000deadbeef()
        s6(x22) = 0x00000000deadbeef()
        s7(x23) = 0x00000000deadbeef()
        s8(x24) = 0x00000000deadbeef()
        s9(x25) = 0x00000000deadbeef()
        s10(x26) = 0x00000000deadbeef()
        s11(x27) = 0x00000000deadbeef()
Function Arguments Registers:
        a0(x10) = 0x000000000151ccb8()
        a1(x11) = 0x0000000000000000()
        a2(x12) = 0x0000000300000000()
        a3(x13) = 0x0000000300000000()
        a4(x14) = 0x00000000deadbeef()
        a5(x15) = 0x0000000000004000()
        a6(x16) = 0x00000000deadbeef()
        a7(x17) = 0x00000000deadbeef()
sstatus = 0x8000000200046020
        Supervisor Interrupt Disabled
        Last Time Supervisor Interrupt Enabled
        Last Privilege is User Mode
        Permit to Access User Page
        Not Permit to Read Executable-only Page
satp = 0x8000000000007ffb
        Current Page Table(Physical) = 0x0000000007ffb000
        Current ASID = 0x0000000000000000
        Mode = Page-based 39-bit Virtual Addressing Mode
-----------------Dump OK---------------------
riscv64-unknown-linux-musl-addr2line -e main.elf -a -f 0000000200000010
[E/DBG] User Fault, killing thread: main.elf

Comparing the disassemblies of the executables compiled with the vendor GCC 12 (left) and the standard GCC 13 (right) I'm seeing the following differences for the specified program counter:
GCC12_left_GCC13_right

I'm suspecting that the problem is that the vendor GCC 12 automatically compiles a number of syscall implementations into every executable. I'm guessing RT-Thread tries to call them and that's why the program crashes. Here are examples of the missing syscalls but there are far more:

syscall_set_thread_area
syscall_shmdt
syscall_timer_delete
...
syscall_stat
syscall_munmap
syscall_setrlimit
syscall_dup2
...
syscall_fallocate
syscall_timerfd_settime
get_rtt_syscall
___syscall
...
__syscall
syscall
__syscall_ret
...
__FUNCTION__.0
...
__FUNCTION__.263
syscall_table

If my assumption is correct, could you please provide the source for those syscalls built into the vendor toolchain?

Reproduction steps

  1. Build toolchain configured like the provided GCC 12 from the source on https://github.com/riscv-collab/riscv-gnu-toolchain with configuration "rv64gc_lp64d_linux_musl_medany".
  2. Write minimal C file:
int main(void)
{
    return 0;
}
  1. Build with rv64gc_lp64d_linux_musl_medany/bin/riscv64-unknown-linux-musl-gcc -march=rv64gc -mabi=lp64d -mcmodel=medany -T k230_rtsmart_linker_scripts/riscv64/link.lds --static main.c -o main.elf
  2. Transfer main.elf to K230 board and execute it on the big core.

Hardware board

CanMV-K230-V1.1

Software version

v1.5

Bug frequency

100%

Anything else

No response

@pfalz-benni pfalz-benni added the bug Something isn't working label Jul 21, 2024
@LearnigF
Copy link

LearnigF commented Jul 26, 2024

@PhilippvK
Copy link

@LearnigF The uploaded patch can not be displayed... Could you please provide it again?

Screenshot from 2024-07-27 12-43-20

@LearnigF
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants