Found out the problem.
The initialization code is using the compression extension (it shouldn't) for this platform.
best, Marcelo
On Wed, Aug 25, 2021 at 2:46 PM Marcelo Politzer < marcelo.politzer@cartesi.io> wrote:
Thanks for the timely reply.
I swapped the application to a hello-world[1] to simplify debugging. Addresses have changed a little (faulting address is now: 0x101d0). `user exception 0x2 code 0 in thread 0xffffffc17fec8200 "rootserver" at address 0x101d0`[2]. Its address resolves to frame_dummy seems to be some gcc specific initialization code (that shouldn't run?)
Since it mentioned registers, I also checked the usage of float (unsupported in this CPU) but that's likely not it (build has emitted soft float functions).
[1]
#include<stdio.h> int main() { printf("hello world\n"); return 0; }[2]
(gdb) disas 0x101d0 Dump of assembler code for function frame_dummy: 0x00000000000101d0 <+0>: j 0x10182 <register_tm_clones> 0x00000000000101d2 <+2>: unimpOn Wed, Aug 25, 2021 at 12:59 PM Axel Heider axelheider@gmx.de wrote:
Marcelo,
I have a suspicion that the unsupported PMP may have something to do with this but since I'm still pretty new to seL4 so I would like advice on how to debug this further.
It can't be the PMP because seL4 starts in S-Mode. What code does the sel4 root task have at the faulting address 0x101f0?
Axel