# Where to find the risc-v default linker script?

**URL:** <https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520>\
**Category:** HiFive1 Rev B\
**Created:** [December 19, 2021, 5:54pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520 "2021-12-19T17:54:13Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![bsvtgc](https://avatars.discourse-cdn.com/v4/letter/b/ce7236/32.png) [@bsvtgc](https://forums.sifive.com/u/bsvtgc)\
**Post date:** [December 19, 2021, 5:54pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/1 "2021-12-19T17:54:13Z")

</div>

I installed the risc-v toolchain on my Mac mini. I wrote a simple assembly code & assembled my asm file (riscv64-unknown-elf-as -march=rv32imac -mno-arch-attr asm.S -o asm.o)

I see the .o file created properly. Now is there any default linker file that I can pick and edit?

---

<div class="post-metadata">

**Author:** ![bsvtgc](https://avatars.discourse-cdn.com/v4/letter/b/ce7236/32.png) [@bsvtgc](https://forums.sifive.com/u/bsvtgc)\
**Post date:** [December 19, 2021, 10:43pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/2 "2021-12-19T22:43:47Z")

</div>

Found sample scripts here: [freedom-e-sdk/bsp/sifive-hifive1-revb at master · sifive/freedom-e-sdk · GitHub](https://github.com/sifive/freedom-e-sdk/tree/master/bsp/sifive-hifive1-revb)

---

<div class="post-metadata">

**Author:** ![pds](https://avatars.discourse-cdn.com/v4/letter/p/8edcca/32.png) [@pds](https://forums.sifive.com/u/pds)\
**Post date:** [December 20, 2021, 5:39pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/3 "2021-12-20T17:39:30Z")

</div>

Good links you found. Might also like a few notes I put together on the same subject:  
[Demystifying OpenOCD … and the smallest toolchain in the world](https://github.com/psherman42/Demystifying-OpenOCD)  
Have a look at the sample .mk mske file and associated .lds linker scripts (for target memory layout),

The `ld` program puts all the relocatable object files together into a single `.elf` file format.

`$(RISCVGNU)-ld start.o foo.o bar.o baz.o ... -T fe310-g002-rom.lds -o my-prog.elf -Map my-prog.map -b elf32-littleriscv`

where `RISCVGNU` is either  
`RISCVGNU ?= riscv32-unknown-elf`  
or, lately,  
`RISCVGNU ?= riscv64-unknown-elf`  
which in case of the latter requires linker option` -b elf32-littleriscv`

Optionally, you can make a program listing of exactly what is being put where, and why.

`$(RISCVGNU)-objdump -D my-prog.elf > my-prog.lst`

Optionally, you can convert the `.elf` file format to Intel hex;

`$(RISCVGNU)-objcopy my-prog.elf -O ihex my-prog.hex`

or, optionally, you can convert the `.elf` file format to binary. The choice (elf, hex, bin) is up to which loader program you will use.

`$(RISCVGNU)-objcopy my-prog.elf -O binary my-prog.bin`

Which loader program and hardware interface connection do you use? If OpenOCD with jtag, you may also find my suggestions in the `.cfg` file very helpful.

---

<div class="post-metadata">

**Author:** ![bsvtgc](https://avatars.discourse-cdn.com/v4/letter/b/ce7236/32.png) [@bsvtgc](https://forums.sifive.com/u/bsvtgc)\
**Post date:** [December 21, 2021, 3:38am UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/4 "2021-12-21T03:38:48Z")

</div>

First, **thank you very much.** your response saved a lot of time. I borrowed your linkerscript fe310-ram.lds and generated a very basic elf to test if toolchain, openocd, gdb all works fine with my hifive1-revb board.  
my entry.s file

> .section .text  
> .global main
> 
> main:  
> addi t0, a0, 100; # loop counter t0 = 100
> 
> loop\_start:  
> beq t0, x0, loop\_end; # exit loop if counter expires  
> addi t0, t0, -1; # decrement counter  
> j loop\_start;  
> loop\_end:  
> addi t1, x0, 0; # dummy instruction

I generated elf with your ram ld file and got the elf as below:

> $riscv64-unknown-elf-objdump -D entry.elf
> 
> entry.elf: file format elf32-littleriscv
> 
> Disassembly of section .text:
> 
> 80000000 :  
> 80000000: 06450293 addi t0,a0,100
> 
> 80000004 \<loop\_start\>:  
> 80000004: 00028463 beqz t0,8000000c \<loop\_end\>  
> 80000008: 12fd addi t0,t0,-1  
> 8000000a: bfed j 80000004 \<loop\_start\>
> 
> 8000000c \<loop\_end\>:  
> 8000000c: 4301 li t1,0

Now, I am just planning to load this directly in RAM (0x80000000) and see if I can keep a breakpoint in main using gdb and step-in. **Do think find anything fatal that might permanently damage my board?** it should n’t, but I am new to risc-v hence seek experts opinion. I dont have any startup code (no interrupt mapping, but this loop code dont need anything).

I ask as I am bit paranoid as I have just one board 🙂

---

<div class="post-metadata">

**Author:** ![pds](https://avatars.discourse-cdn.com/v4/letter/p/8edcca/32.png) [@pds](https://forums.sifive.com/u/pds)\
**Post date:** [December 21, 2021, 7:17pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/5 "2021-12-21T19:17:53Z")

</div>

Most welcome @bsvtgc Vincent, glad it helps. Great little code example and disassembly you’ve tested. Sure, nothing bad will happen, especially if it only loads to ram – power off, reset, or unplug and it’s back to “normal”. I do this all the time.

After, or in place of your “dummy” instruction, you might want to put a forever loop with

`j . ;# or, jal x0, .`

so that the core stops in its tracks and doesn’t try to execute unknown code at unknown places.

I’ve never had a HiFive board, and have never used the Freedom GUI toolchain package, so I am not much the expert there but am confident nothing bad will happen. I have and use the LoFive board; and for debugger interfaces both the Raspberry Pi (bitbang jtag) and the FTDI FT(2)232H chip (Olimex, etc).

You might wish to revise your openocd “.cfg” file with some of my suggestions. The HiFive has a built-in J-Link USB device, so only “interface” (or, lately, called “adapter”) section is probably different.

As long as you use `load_image` and **not** `flash write_image` (or equiv. flash submodules) then you’ll be fine and not touch the rom chip contents.

Let me repeat this critical point: For ram-only work, _comment out, or remove, any and all lines_ beginning with “flash”, such as

```auto
# flash bank ...
# flash protect ...
# flash erase ...
# flash write_image ...

```

or even the helper script, if it exists in your .cfg,

```auto
# program ...

```

A handy openocd reference is [OpenOCD Command Reference](https://www.openocd.org/doc/html/Flash-Commands.html) in case you’re interested.

* * *

I have encapsulated all necessary steps into a single [tcl] procedure, `asic_ram_load`, which you would invoke like so:

```auto
openocd -f fe310-g002.cfg -c "adapter speed 2000" -c init -c "asic_ram_load my_prog" -c shutdown -c exit

```

where `my_prog` is whatever is the name of your binary file. Change lines 150 and 151 if you don’t put the “-ram” suffix on your filename, or use another format beside “bin”.

I am not sure how the jlink chip on the HiFive board ([schematic](https://sifive.cdn.prismic.io/sifive/c34f4c7f-0d3a-493e-8a19-a0b18f8a4555_hifive1-b01-schematics.pdf), sheet 4, U3-64, PTD7) handles reset; thus, you might only want to take my high level procedures in the “APPLICATIONS” section at the bottom. Further work to check and revise lines 78-81 whether jlink uses trst, srst, or some other hardware signal. For now, keeping all the command handlers as-is, un-overridden, gives benefit of doubt.

You might like to keep hardware interface specific stuff (such as the `adapter driver jlink` statement; see [tips on HiFive connection](https://forums.sifive.com/t/openocd-config-file-for-hifive1-revb/3930) for suggestions) in another config file. If so, you would invoke like so:

`openocd -f hifive-rev-b.cfg -f fe310-g002.cfg ...`

Just make sure that the first .cfg file doesn’t have any init statement; it should be put in only at the right sequence, such as at the command line:

1. hardware-specific-interface-stuff
2. target-specific-stuff
3. speed
4. init
5. high-level-application-command
6. shutdown
7. exit  
For interactive gdb sessions, omit 6 and 7.

---

<div class="post-metadata">

**Author:** ![bsvtgc](https://avatars.discourse-cdn.com/v4/letter/b/ce7236/32.png) [@bsvtgc](https://forums.sifive.com/u/bsvtgc)\
**Post date:** [December 23, 2021, 8:49pm UTC](https://forums.sifive.com/t/where-to-find-the-risc-v-default-linker-script/5520/6 "2021-12-23T20:49:12Z")

</div>

@pds when I tried with your “openocd config and command”

> openocd -f demo.cfg -c “adapter speed 2000” -c init -c “asic\_ram\_load my\_prog” -c shutdown -c exit

with hifive1-revb board connected, it threw up the following error.

**[OpenOCD: Bug Reporting](http://openocd.org/doc/doxygen/bugs.html)**  
**Error: Debug adapter doesn’t support any transports?**  
\*\*demo.cfg:22: Error: \*\*  
**in procedure ‘script’**

However, when I took another config file from GitHub and slightly modified based on your inputs (removed anything related with flash) it came to the following:

> adapter speed 4000  
> adapter driver jlink  
> transport select jtag  
> set \_CHIPNAME riscv  
> jtag newtap $\_CHIPNAME cpu -irlen 5 -expected-id 0x20000913
> 
> set \_TARGETNAME $\_CHIPNAME.cpu
> 
> target create $\_TARGETNAME.0 riscv -chain-position $\_TARGETNAME  
> $\_TARGETNAME.0 configure -work-area-phys 0x80000000 -work-area-size 0x4000 -work-area-backup 0
> 
> riscv set\_enable\_virt2phys off  
> riscv set\_enable\_virtual off  
> init  
> jlink jtag 3
> 
> halt

with openocd & gdb up, I found a bug on first line of my code 🙂  
addi t0, a0, 100; # loop counter t0 = 100 =\> addi t0, **x0,** 100;

I really appreciate your help with all the details you put in your message. Thanks !!

I r **eally like the way your openocd config is written, clean and customizable**. But I am not an expert on openocd. do you think the transport protocol should be mentioned somewhere in .cfg file or through command to be used for hifive1-revb board. I read hifive1-revb is quite different from hifive1.