lupyuen/nuttx-star64
1
0
Fork 0
mirror of https://github.com/lupyuen/nuttx-star64.git synced 2025-01-13 05:08:31 +08:00
Code Issues Projects Releases Packages Wiki Activity Actions

Scheme runs OK on Star64 yay!

Browse source
This commit is contained in:
Lee Lup Yuen 2023-10-14 17:55:57 +08:00
parent 1b059d5d93
commit 84c1a5e0ae
1 changed files with 19 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
README.md
View file

@ -8090,6 +8090,17 @@ MTVAL: 0000000000000030
Exception Program Counter is `c000f366`. We disregard the `c000` because NuttX maps the Scheme App into the RISC-V User Memory Space at `c0000000`. So actual Program Counter is `f366` Exception Program Counter is `c000f366`. We disregard the `c000` because NuttX maps the Scheme App into the RISC-V User Memory Space at `c0000000`. So actual Program Counter is `f366`
```bash
CONFIG_ARCH_DATA_NPAGES=128
CONFIG_ARCH_DATA_VBASE=0xC0100000
CONFIG_ARCH_HEAP_NPAGES=128
CONFIG_ARCH_HEAP_VBASE=0xC0200000
CONFIG_ARCH_TEXT_NPAGES=128
CONFIG_ARCH_TEXT_VBASE=0xC0000000
```
[(Source)](https://github.com/apache/nuttx/blob/master/boards/risc-v/jh7110/star64/configs/nsh/defconfig#L25-L39)
We look up `f366` in the disassembly... We look up `f366` in the disassembly...
```bash ```bash
@ -8332,15 +8343,15 @@ TODO: Why is Interrupt Stack full again?
TODO: Explore [Run Time Stack Checking](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629451#content/view/139629451) TODO: Explore [Run Time Stack Checking](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629451#content/view/139629451)
Check the next section for the Stack Dump analysis... Read on to find out what caused the App Stack to overflow...
# Analyse the Stack Dump for Scheme Interpreter # Analyse the Stack Dump for Scheme Interpreter
TODO: Enable "RTOS Features > Stack Backtrace" in menuconfig (SCHED_BACKTRACE) TODO: Enable "RTOS Features > Stack Backtrace" in menuconfig (SCHED_BACKTRACE)
_In the previous section, we saw the Scheme App crashing on NuttX QEMU..._ _In the previous section, we saw the Scheme App crashing on NuttX QEMU due to Stack Overflow..._
_What are the Function Calls leading to the crash?_ _But why? What are the Function Calls leading to the crash?_
Let's construct the Stack Backtrace. We search for other Code Addresses in the Stack Dump above... Let's construct the Stack Backtrace. We search for other Code Addresses in the Stack Dump above...
@ -8373,6 +8384,8 @@ c000fc58
We match the above Code Addresses to the Scheme App Disassembly (from the previous section). We match the above Code Addresses to the Scheme App Disassembly (from the previous section).
[(Remember to disregard the `c00` prefix because that's the RISC-V User Memory Space)](https://github.com/apache/nuttx/blob/master/boards/risc-v/jh7110/star64/configs/nsh/defconfig#L25-L39)
Note that these Code Addresses are the __Return Addresses__. So we look up the Previous Instruction that appears in the Scheme App Disassembly... Note that these Code Addresses are the __Return Addresses__. So we look up the Previous Instruction that appears in the Scheme App Disassembly...
```text ```text
@ -8497,7 +8510,9 @@ When we read the Function Calls from bottom to top...
(Scheme App tries to get the Symbol Token's Internal Name and crashes here) (Scheme App tries to get the Symbol Token's Internal Name and crashes here)
TODO: Interpret the calls _So why did the Scheme App crash with a Stack Overflow?_
TODO: Recursion
# TODO # TODO