# How to boot directly from RAM **URL:** \ **Category:** HiFive1 Rev B\ **Created:** [October 15, 2020, 1:45am UTC](https://forums.sifive.com/t/how-to-boot-directly-from-ram/4110 "2020-10-15T01:45:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![nate831](https://avatars.discourse-cdn.com/v4/letter/n/3ab097/32.png) [@nate831](https://forums.sifive.com/u/nate831)\ **Post date:** [October 15, 2020, 1:45am UTC](https://forums.sifive.com/t/how-to-boot-directly-from-ram/4110/1 "2020-10-15T01:45:18Z")
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. @vndao ---
**Author:** ![dconn](https://avatars.discourse-cdn.com/v4/letter/d/b4bc9f/32.png) [@dconn](https://forums.sifive.com/u/dconn)\ **Post date:** [October 15, 2020, 10:08pm UTC](https://forums.sifive.com/t/how-to-boot-directly-from-ram/4110/2 "2020-10-15T22:08:32Z")
Hi, 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. ---
**Author:** ![nate831](https://avatars.discourse-cdn.com/v4/letter/n/3ab097/32.png) [@nate831](https://forums.sifive.com/u/nate831)\ **Post date:** [October 16, 2020, 12:32am UTC](https://forums.sifive.com/t/how-to-boot-directly-from-ram/4110/3 "2020-10-16T00:32:56Z")
> [@dconn](#): > > LINK\_TARGET = default Thanks for the reply David. 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). ---
**Author:** ![pds](https://avatars.discourse-cdn.com/v4/letter/p/8edcca/32.png) [@pds](https://forums.sifive.com/u/pds)\ **Post date:** [October 18, 2020, 9:59pm UTC](https://forums.sifive.com/t/how-to-boot-directly-from-ram/4110/4 "2020-10-18T21:59:43Z")
@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. ![Screen Shot 2020-10-18 at 5.19.55 PM](https://us1.discourse-cdn.com/flex020/uploads/sifive/original/2X/4/486a4526e6bcfc38b5900416ca9e1e27fb7f2ea6.jpeg) ![Screen Shot 2020-10-18 at 2.57.00 PM](https://us1.discourse-cdn.com/flex020/uploads/sifive/original/2X/e/e53c355c06088984637fbc64089c9a9c30789e1f.jpeg) ![Screen Shot 2020-10-18 at 2.57.07 PM](https://us1.discourse-cdn.com/flex020/uploads/sifive/original/2X/9/9d9a2752df2b4b7f1911396c4fca54605a646c4e.jpeg) ![Screen Shot 2020-10-18 at 2.57.13 PM](https://us1.discourse-cdn.com/flex020/uploads/sifive/original/2X/d/d7794bb3e491a70ca9fe7277a49c4978bd5f0b1f.png)