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.