RTEMS | noelv: DTB parsing is broken (#5383)
Matteo Concas (@matteo.concas)
gitlab at rtems.org
Sat Nov 1 18:38:19 UTC 2025
Matteo Concas commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5383#note_135544
> After looking at grmon4 a bit, it occurs to me that grmon does not support emulation
Indeed GRMON is only used to connect to hardware, we also have TSIM for simulation but we don't provide a trial version of the NOEL-V one.
>From more testing, I have noticed that this misaligned load is executed twice. The first time during system initialization when the DTB is parsed to find the end of the memory area in `bsp_memory_initialize()`. The CPU then goes to the exception handler as expected and `_Terminate()` is called. But, on system termination information is printed out to the console, to do that `printk()` which in turn will call `riscv_output_char_init()` and this function probe the FDT to find the console. During this parsing the same error is encountered but this time the exception handler is never entered.
I suspect that is because of the [double trap extension (Smdbltrp)](https://docs.riscv.org/reference/isa/priv/smdbltrp.html) when combined with the [Resumable Non-Maskable Interrupts extension (Smrnmi)](https://docs.riscv.org/reference/isa/priv/rnmi.html#rnmi). In this case, if a double trap happens the RNMI handler should be called but RTEMS doesn't set this anywhere as far as I know meaning `pc` is set to whatever the reset value of the RNMI is (which is implementation defined). I need to check the CSR address in NOEL-V (also implementation defined) and then decide what we want to do in that case? Calling the exception handler a third time won't work obviously..
Showing the double exception along with a register dump:
```
grmon4> bp _RISCV_Exception_handler
Software breakpoint 1 at <_RISCV_Exception_handler>
grmon4> run
CPU 0: Breakpoint 1 hit
0x0000000000005c7c: eb010113 addi sp, sp, -336 <$xrv64i2p1_m2p0_a2p1_f2p2_d2p2_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0+0>
CPU 1: Forced into debug mode
0x00000000000000ac: ffdff06f j 0xa8
grmon4> inst 10
TIME L P ADDRESS INSTRUCTION RESULT SYMBOL
95902 1 M 000000000000e5e4 beqz a0, 0xe5f0 [0000000000000000] fdt_get_property_namelen_+0xe8
95907 0 M 000000000000e5e8 lw a5, 12(sp) [000000000000000e] fdt_get_property_namelen_+0xec
95907 1 M 000000000000e5ec beq a5, s3, 0xe65c [000000000000000e] fdt_get_property_namelen_+0xf0
95982 0 M 000000000000e65c mv a2, s3 [000000000000000e] fdt_get_property_namelen_+0x160
95983 0 M 000000000000e660 mv a1, s6 [0000000000018a70] fdt_get_property_namelen_+0x164
95983 1 M 000000000000e664 jal ra, 0x13e38 [000000000000e668] fdt_get_property_namelen_+0x168
95985 0 M 0000000000013e38 li a3, 7 [0000000000000007] memcmp+0x0
95985 1 M 0000000000013e3c bgeu a3, a2, 0x13e5c [0000000000000007] memcmp+0x4
95986 0 M 0000000000013e40 ld a4, 0(a0) [MISALIGNED LOAD 000000000001b5f9] memcmp+0x8
96057 0 M 0000000000005c7c addi sp, sp, -336 [ BREAKPOINT ] $xrv64i2p1_m2p0_a2p1_f2p2_d2p2_zicsr2p0_zmmul1p0_zaamo1p0_zalrsc1p0+0x0
grmon4> cont
CPU 0: Error mode (4, Load address misaligned)
0x0000000030011000: 0000 illegal instruction
CPU 1: Forced into debug mode
0x00000000000000ac: ffdff06f j 0xa8
grmon4> inst 10
TIME L P ADDRESS INSTRUCTION RESULT SYMBOL
103960 1 M 000000000000e428 ret [000000000000e42c] fdt_get_string+0x120
103962 1 M 000000000000e5e4 beqz a0, 0xe5f0 [0000000000000000] fdt_get_property_namelen_+0xe8
103967 0 M 000000000000e5e8 lw a5, 12(sp) [000000000000000a] fdt_get_property_namelen_+0xec
103967 1 M 000000000000e5ec beq a5, s3, 0xe65c [000000000000000a] fdt_get_property_namelen_+0xf0
103974 0 M 000000000000e65c mv a2, s3 [000000000000000a] fdt_get_property_namelen_+0x160
103975 0 M 000000000000e660 mv a1, s6 [0000000000018858] fdt_get_property_namelen_+0x164
103975 1 M 000000000000e664 jal ra, 0x13e38 [000000000000e668] fdt_get_property_namelen_+0x168
103977 0 M 0000000000013e38 li a3, 7 [0000000000000007] memcmp+0x0
103977 1 M 0000000000013e3c bgeu a3, a2, 0x13e5c [0000000000000007] memcmp+0x4
103978 0 M 0000000000013e40 ld a4, 0(a0) [MISALIGNED LOAD 000000000001b5dc] memcmp+0x8
grmon4> reg
a0: 000000000001b5dc t0: 00000000000000e0 s0: 0000000000000050
a1: 0000000000018858 t1: 0000000000000000 s1: 000000000001a3d8
a2: 000000000000000a t2: 0000000000014648 s2: 00000000000601c8
a3: 0000000000000007 t3: 0000000000000001 s3: 000000000000000a
a4: 000000000001b5e0 t4: 0000000000000000 s4: 0000000000000003
a5: 000000000000000a t5: 0000000000000000 s5: 0000000000000009
a6: 0000000000000000 t6: 0000000000000000 s6: 0000000000018858
a7: ffffffffffffffff s7: 0000000000000004
s8: 00000000000601ac
Machine mode sp: 0000000000060130 s9: 000000000001a460
FPU dirty state tp: 0000000000000000 s10: 0000000000000000
IRQ disabled gp: 000000000005bc48 s11: 0000000000000000
ra: 000000000000e668 <fdt_get_property_namelen_+0x16c>
pc: 0000000030011000 illegal instruction
grmon4> reg mtvec mepc mtval mcause mstatus
mtvec = 23676 (0x0000000000005c7c)
mepc = 81472 (0x0000000000013e40)
mtval = 112121 (0x000000000001b5f9)
mcause = 4 (0x0000000000000004)
mstatus = 9223376477850990592 (0x8000040a00007800)
```
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5383#note_135544
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20251101/b9a09b25/attachment.htm>
More information about the bugs
mailing list