# Difficulties with BCC2 mkprom-hello example

**URL:** <https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122>\
**Category:** General - Software\
**Created:** [26 April 2021 08:52 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122 "2021-04-26T08:52:36Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![lcvisser](https://avatars.discourse-cdn.com/v4/letter/l/a5b964/32.png) [@lcvisser](https://discourse.grlib.community/u/lcvisser)\
**Post date:** [26 April 2021 08:52 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/1 "2021-04-26T08:52:36Z")

</div>

I’m trying to get acquainted with the toolchains for LEON3 and following the README in bcc2/src/examples/mkprom-hello, but I am unable to get it to work.

From the instructions:

> - hello.prom contains the boot loader and a compressed version of hello.elf. It is linked for storage in non-volatile memory, typically on address 0x00000000.

I can get hello.elf running from RAM successfully.

My target is a LEON3 on a Digilent Arty A7 board. I flash the example from grlib/designs/leon3-digilent-arty-a7 unmodified. From the README I understand that I need to make sure that the binary ends up at 0x400000, because the lower portion of the flash is reserved for the FPGA bitstream (relevant quote at the end). Hence, I compiled the example with (0x400000 = 4194304):

```
$ make CFLAGS="-mcpu=leon3 -msoft-float" MKPROMOPT="-leon3 -freq 81 -baud 38352 -rstaddr 4194304"

```

Verify the start address:

```auto
$ sparc-gaisler-elf-objdump -x hello.prom 

hello.prom: file format elf32-sparc
hello.prom
architecture: sparc, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0x00400000

```

Flash it to ROM:

```auto
grmon3> spim flash load hello.prom
            400000 .text 46.3kB / 46.3kB [===============>] 100%
  Total size: 46.31kB (821.49bit/s)
  Entry point 0x00400000
  Image /.../examples/mkprom-hello/hello.prom loaded

```

Trying to run it:

```auto
grmon3> reset

grmon3> run
  Exception (tt = 0x02, illegal instruction)
  0x00400000: ffffffff unknown opcode: 0xffffffff

```

I don’t see anything on /dev/ttyUSB1 either (using screen). Checking the first few instructions:

```auto
grmon3> mem 0
  0x00000000 88100000 09001000 81c120b0 01000000 .......... .....
  0x00000010 a1480000 a7500000 10800177 ac102001 .H...P.....w.. .
  0x00000020 91d02000 01000000 01000000 01000000 .. .............
  0x00000030 91d02000 01000000 01000000 01000000 .. .............
  
grmon3> dis 0 4
       0x00000000: 88100000 clr %g4                 
       0x00000004: 09001000 sethi %hi(0x400000), %g4
       0x00000008: 81c120b0 jmp %g4 + 0xb0          
       0x0000000c: 01000000 nop        

```

**What am I missing?**

* * *

From README in designs/leon3-digilent-arty-a7:

> Typically the lower part of the SPI flash device will hold the configuration bitstream for the FPGA. The SPIMCTRL core is configured with an offset value that will be added to the incoming AHB address  
> before the address is propagated to the SPI flash device. The default offset is 0x00400000 (this value is set via xconfig and the constant is called CFG\_SPIMCTRL\_OFFSET). When the processor starts after power-up it will read address 0x0, this will be translated by SPIMCTRL to 0x00400000.

> SPIMCTRL can only add this offset to accesses made via the core’s memory area. For accesses made via the register interface the offset must be taken into account. This means that if we want to program the Flash with an application which is linked to address 0x0 (our typical bootloader) then we need to add the offset 0x00400000 before programming the file with GRMON. We load the Flash with our application starting at 0x00400000 and SPIMCTRL will then translate accesses from AMBA address 0x0 + n to Flash address 0x00400000 + n.

---

<div class="post-metadata">

**Author:** ![arvid](https://dub1.discourse-cdn.com/flex017/user_avatar/discourse.grlib.community/arvid/32/12_2.png) [@arvid](https://discourse.grlib.community/u/arvid)\
**Post date:** [27 April 2021 13:22 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/2 "2021-04-27T13:22:53Z")

</div>

Hello,

You can use objcopy to change the load address of all the sections. Remove the -rstaddr option to mkrprom2 so the application is linked to address 0x0. Then you will load data to 0x400000 but run the application from 0x0.

sparc-gaisler-elf-objcopy --change-section-lma \*+0x400000 hello.prom hello.spim

---

<div class="post-metadata">

**Author:** ![lcvisser](https://avatars.discourse-cdn.com/v4/letter/l/a5b964/32.png) [@lcvisser](https://discourse.grlib.community/u/lcvisser)\
**Post date:** [27 April 2021 20:30 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/3 "2021-04-27T20:30:05Z")

</div>

Thanks @arvid , but unfortunately, that doesn’t seems to change much. The error goes away, but now GRMON complains: “No entry point set!”:

```auto
grmon3> reset
  
grmon3> run
  No entry point set!

```

The second instruction is different now (`sethi(0)` instead of `sethi(0x400000)`) and matches with the example in the MKPROM manual:

```auto
grmon3> dis 0 4
       0x00000000: 88100000 clr %g4          
       0x00000004: 09000000 sethi %hi(0), %g4
       0x00000008: 81c120b0 jmp %g4 + 0xb0   
       0x0000000c: 01000000 nop      

```

I guess I have some debugging to do, but ideas are welcome in the meantime…!

---

<div class="post-metadata">

**Author:** ![arvid](https://dub1.discourse-cdn.com/flex017/user_avatar/discourse.grlib.community/arvid/32/12_2.png) [@arvid](https://discourse.grlib.community/u/arvid)\
**Post date:** [28 April 2021 05:55 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/4 "2021-04-28T05:55:53Z")

</div>

Uet the command “ep 0” to set the entry point manually, or add it to the run command “run 0”

---

<div class="post-metadata">

**Author:** ![lcvisser](https://avatars.discourse-cdn.com/v4/letter/l/a5b964/32.png) [@lcvisser](https://discourse.grlib.community/u/lcvisser)\
**Post date:** [28 April 2021 17:27 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/5 "2021-04-28T17:27:41Z")

</div>

```auto
grmon3> reset
  
grmon3> run 0
  Error mode (tt = 0x04, fp disabled)
  0x000005f4: 91d02000 ta 0

```

Different error than before… I guess my next learning goal is to attach the debugger.

---

<div class="post-metadata">

**Author:** ![lcvisser](https://avatars.discourse-cdn.com/v4/letter/l/a5b964/32.png) [@lcvisser](https://discourse.grlib.community/u/lcvisser)\
**Post date:** [29 April 2021 19:47 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/6 "2021-04-29T19:47:55Z")

</div>

I think I got a bit further. The trap lead me to finding out that the out-of-the-box design had SVT enabled. So I recompiled with `-qsvt`:

```auto
make CFLAGS="-mcpu=leon3 -msoft-float -qsvt" MKPROMOPT="-leon3 -qsvt -freq 81 -baud 38425"

```

Unfortunately, that didn’t change anything:

```auto
grmon3> run
  Error mode (tt = 0x04, fp disabled)
  0x0000063c: 91d02000 ta 0 <_prom_srmmu_fault+0>

```

I see that the design also has the MMU disabled, but I can’t directly identify a flag for MKPROM related to it. Or is `_prom_srmmu_fault` a red herring?

---

<div class="post-metadata">

**Author:** ![arvid](https://dub1.discourse-cdn.com/flex017/user_avatar/discourse.grlib.community/arvid/32/12_2.png) [@arvid](https://discourse.grlib.community/u/arvid)\
**Post date:** [30 April 2021 07:50 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/7 "2021-04-30T07:50:31Z")

</div>

It looks like you have used “info mkprom2” in GRMON. That output is a suggestion, you should sanity check the values. For example the baudrate should probably be the standard 38400. And the frequency seem to be a bit odd (should it be 80MHz?), note that GRMON detects the wrong frequency sometimes (in which case you should provide the correct frequency to GRMON with the commandline flag -freq ).

It error indicates that you trying to use the floating-point unit, but its turned of or missing. You can verify this by looking at the instruction trace (“inst 1000” in GRMON), and you should see either a floating point instruction issued or a floating point register being used.

You need to provide -msoft-float to mkprom2 as well.

It’s probably a good idea to go through the commandline options of mkprom2 in the manual to see if you are missing anything else.

---

<div class="post-metadata">

**Author:** ![lcvisser](https://avatars.discourse-cdn.com/v4/letter/l/a5b964/32.png) [@lcvisser](https://discourse.grlib.community/u/lcvisser)\
**Post date:** [1 May 2021 14:00 UTC](https://discourse.grlib.community/t/difficulties-with-bcc2-mkprom-hello-example/122/8 "2021-05-01T14:00:27Z")

</div>

@arvid thanks so much! I can’t believe I forgot to add `-msoft-float` to the options for MKPROM, it’s even the first one in the list in the manual… Adding that flag and setting the baudrate to 38400 solved it and the example is working as expected.

As an aside: I was wondering about how to sanity check the baud rate. I noticed that subsequent calls to `info mkprom2` would give different values for frequency and baudrate. The frequency I can cross-check with the design files (83 MHz is set there), but while the baudrate didn’t make sense initially, I also couldn’t find a way how to check it.