I notice there are a couple of metal linker scripts that come with any example project for HiFive1 RevB using Freedom Metal, such as Hello World.
It appears “metal.default.lds” is the default linker script, and this targets your program into flash, so the bootloader can copy it into RAM and execute. This in practice works fine for me.
I have come to understand “metal.scratchpad.lds” is setup to target your program directly into RAM.
question #1: How can I debug and run my application such that the HiFive1 RevB board I am using runs the program directly from RAM?
We tried hacking /SiFive/freedom-e-sdk-v20.05.00.02/scripts/standalone.mk by adding this line: RISCV_LDFLAGS += -L$(sort (dir (abspath (filter %.a,^)))) -T/C/FreedomStudio/2020-06-3-win64/SiFive/freedom-e-sdk-v20.05.00.02/bsp/qemu-sifive-e31/metal.scratchpad.lds
Based on the console output when compiling, this is the linker script which is used to generate hello.elf. I don’t think hacking standalone.mk is the right way, which brings me to question #2: What is the preferred method for choosing a linker script for a given project?
So with the .elf generated via the hack to prefer the scratchpad linker script when we tried to debug, we noticed the CPU was stuck in the early_trap_vector loop due to an ‘mcause’ of 0x7: “Store/AMO access fault.”
Looking at ‘mepc’, we see that the offending instruction is: ‘0x8000021a’ which already looks suspect on alignment alone.
If you are compiling on the command line you can specify LINK_TARGET=scratchpad as part of your build command (type make help in the freedom-e-sdk path to see all options), or if you are using Freedom Studio, simply modify the line in the Makefile: LINK_TARGET = default to LINK_TARGET = scratchpad. You should not have to touch standalone.mk.
I tried this and it seemed to do the trick so no more hacking of standalone.mk. Now I am trying to compile hello world such that the program will exist in RAM starting at 0x80000000 on the HiFive1 RevB board. Is LINK_TARGET=scratchpad a valid flow for the board I am using? Maybe I don’t understand what this mode is supposed to do
If I set a breakpoint at main, it never triggers and the debugger kind of goes crazy (bunch of failures to read).
@nate831 Shown below are pictures of how to selectively boot and run program code from Flash or RAM. Briefly, there are two steps:
First, change the destinations of the text and rodata sections in the linker .lds file from “rom” to “ram”. Leave the bss section always destined to RAM.
Second, use the load_image (and, optionally an additional verify_image) command of openocd with target address 0x80000000 to load the program into RAM; when Flash execution is desired, use instead the “flash write_image” command with target address 0x20000000. To run the program from RAM or Flash, use the resume command of openocd with address 0x80000000 or 0x20000000, respectively.
