sifive / freedom-u540-c000-bootloader

Freedom U540-C000 Bootloader Code

This project builds 3 binaries:

1. zsbl, the zero stage bootloader.
2. fsbl, the first stage bootloader.
3. board_setup, a binary based on fsbl that configures the hardware in hart 0 and then executes ebreak. The other harts are parked in an infinite loop. It's intended to be used from OpenOCD to quickly prepare a HiFive Unleashed board for code to be downloaded into its DDR memory.

freedom-u540-c000-bootloader's Issues

Your license template needs finished

Check the bottom

This version did not do the full linux boot.

how to use fsbl.bin in HighFive Unleashed board ?

I have made some changes to the device tree and generated the fsbl.bin. How do I update that in Unleashed ?
Chapter 6 in Unleashed starting guide only talks about steps to update complete firmware hifive-unleashed-a00-A.B-YYYY-MM-DD.gpt. This also contains the FSBL, DTB, and recovery kernel.

What is the best procedure to generate the .gpt file ?

@palmer-dabbelt @terpstra @tmagik

Fails to build with clang

I was trying to use clang cross compiler to build it and it showed up two issues

1. Use gcc specific commandline option -mexplicit-relocs in Makefile
2. Fails to compile code using atomics

ux00boot/ux00boot.c:505:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)                                                                               
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), UX00BOOT_ERROR_LED_GPIO_MASK);                                                                                         
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'                         
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)                                                               
                                         ^                     ~~~~~~
ux00boot/ux00boot.c:506:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)                                                                                                                                                                  
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_EN), UX00BOOT_ERROR_LED_GPIO_MASK);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                           
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~
ux00boot/ux00boot.c:507:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)                                                                               
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_XOR), UX00BOOT_ERROR_LED_GPIO_MASK);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'          
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~                                                                                                
3 errors generated.
ux00boot/ux00boot.c:505:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), UX00BOOT_ERROR_LED_GPIO_MASK);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~
make: *** [Makefile:62: zsbl/ux00boot.o] Error 1
make: *** Waiting for unfinished jobs.... 
ux00boot/ux00boot.c:506:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_EN), UX00BOOT_ERROR_LED_GPIO_MASK);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~
ux00boot/ux00boot.c:507:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') inval
id)
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_XOR), UX00BOOT_ERROR_LED_GPIO_MASK);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~
3 errors generated.
make: *** [Makefile:68: fsbl/ux00boot.o] Error 1
fsbl/main.c:129:5: error: second parameter of 'main' (argument array) must be of type 'char **'
int main(int id, unsigned long dtb)
    ^
fsbl/main.c:276:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') invalid)
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_VAL), PHY_NRESET);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/u540-c000-bootloader/gitAUTOINC+128f282d17-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/stdatomic.h:138:4
2: note: expanded from macro 'atomic_fetch_or'
#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
                                         ^                     ~~~~~~
fsbl/main.c:277:3: error: address argument to atomic operation must be a pointer to _Atomic type ('volatile uint32_t *' (aka 'volatile unsigned int *') invalid)
  atomic_fetch_or(&GPIO_REG(GPIO_OUTPUT_EN),  PHY_NRESET);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

undefined reference to `__libc_detect_null'

The function __libc_detect_null is not defined anywhere.

gcc -I. -O2 -ggdb -march=rv64imafdc -mabi=lp64d -Wall -mcmodel=medany -mexplicit-relocs -nostdlib -nostartfiles -o fsbl.elf fsbl/start.o fsbl/main.o spi/spi.o uart/uart.o lib/version.o ememoryotp/ememoryotp.o fsbl/ux00boot.o clkutils/clkutils.o gpt/gpt.o fdt/fdt.o sd/sd.o lib/memcpy.o lib/memset.o lib/strcmp.o lib/strlen.o fsbl/dtb.o -Tux00_fsbl.lds
/usr/lib64/gcc/riscv64-suse-linux/8/../../../../riscv64-suse-linux/bin/ld: lib/strlen.o: in function strlen': /suse/schwab/src/riscv/sifive/freedom-u540-c000-bootloader/lib/strlen.c:38: undefined reference to __libc_detect_null'
collect2: error: ld returned 1 exit status

Why is zsbl/ux00_zsbl.dts different from fsbl/ux00_zsbl.dts

Can I use the dts file generated by freedom for one of them?
Thanks.

what does unimp a0 a1 mean?

I am reading fsbl/main.c, and I see some code at line 404-424:

int slave_main(int id, unsigned long dtb)
{
  // Wait for the DTB location to become known
  while (!dtb_target) {}

  //wait on barrier, disable sideband then trap to payload at PAYLOAD_DEST
  write_csr(mtvec,PAYLOAD_DEST);

  register int a0 asm("a0") = id;
#ifdef SKIP_DTB_DDR_RANGE
  register unsigned long a1 asm("a1") = dtb;
#else
  register unsigned long a1 asm("a1") = dtb_target;
#endif
  // These next two guys must get inlined and not spill a0+a1 or it is broken!
  Barrier_Wait(&barrier, NUM_CORES);
  ccache_enable_ways(CCACHE_CTRL_ADDR,14);
  asm volatile ("unimp" : : "r"(a0), "r"(a1));

  return 0;
}

What does asm volatile ("unimp" : : "r"(a0), "r"(a1)); mean? It sinces there is no unimp in riscv specs.

Bootrom challenge notes

I started annotating the bootrom dump at https://gist.github.com/zhuowei/d6ff16f05faf13ba9e946345d4840db6. I generated the dump with Objdump:

riscv64-unknown-elf-objcopy --change-addresses=0x10000 -I binary -O elf64-littleriscv -B riscv bootrom.bin bootrom.elf
riscv64-unknown-elf-objdump -DrCt bootrom.elf >dumped.txt

and added the method names by comparing the disassembly with the disasembly of the zsbl built from this repo using the latest (2018.7) SiFive toolchain.

---

Edit 1: Pushed my changes to https://github.com/zhuowei/freedom-u540-c000-bootloader/tree/tweaking

Building this repo with both the 2018-07 toolchain and the oldest toolchain I can find (20170503), the

call main

pseudoinstruction in start.S compiles to a jal, but in the bootrom it compiles to a pair of auipc/jalr instructions:

   100ca:	00000097          	auipc	ra,0x0
   100ce:	05a080e7          	jalr	90(ra)

I tried both code models and that didn't make a difference either. Otherwise _prog_start is identical to the bootrom version (except for the offsets) once SKIP_ECC_WIPEDOWN is defined.

---

Edit 2:

I switched to the 20170503 toolchain, since it generates identical code for init_uart as the bootrom code, while the latest toolchain generates it in a different order.

I tried passing in -Wl,--no-relax to the linker to solve the auipc/jalr issue; this doesn't work: this changes all the calls to methods to auipc/jalr pairs, but some calls such as the call to handle_trap in trap_entry and the call to ux00boot_load_gpt_partition in main do use the shorter single jal instruction. This suggests that the bootrom was built with a compiler similar to the 20170503 release, but with a linker that has different support for relaxation.

I don't know how to proceed from here. Try even older compilers?

---

Edit 3: the dtb in the bootrom is also slightly different from the dts file included here: https://gist.github.com/zhuowei/d6ff16f05faf13ba9e946345d4840db6#file-gistfile1-txt

device tree error

ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
can i know what the error is

a memcpy bug(possibly)

freedom-u540-c000-bootloader/lib/memcpy.c

Line 23 in 24f612f

memcpy(void *__restrict aa, const void *__restrict bb, size_t n)

aa,bb are restricted pointer and it's value cannot be modified by other pointers.
but in BODY by

freedom-u540-c000-bootloader/lib/memcpy.c

Line 28 in 24f612f

*(a - 1) = tt; \

the value of aa is modified.

I may be wrong, but this solves the problem of infinite loops in memcpy functions in some cases.

memcpy(void * aa, const void * bb, size_t n)

cannot understand ccache_sideband

Hi,
I was reading the zsbl linker script. In that I am unable understand ccache_sideband. which is used to store all the data sections and stack segment. Please can someone help in understanding this. any related links will be helpfull.

location of ROM binary?

https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom-u540-c000s-bootloader/ links to this repository as the location for a copy of the ROM contents, but there doesn't appear to be a non-source, binary file here?

Merging build-fixes branch to master?

I just ran into #15 which has been fixed on the build-fixes branch but never merged to master.

Is there a reason for keeping these fixes on a different branch, or could they be merged to master?