Challenge

[esmil]

This solves the challenge, at least with my toolchain:

$ make
...
$ diff -sq u540-c000-release/bootrom.bin zsbl.bin 
Files u540-c000-release/bootrom.bin and zsbl.bin are identical

[esmil]

The toolchain used to generate the original bootrom.bin seems to choose whether to relax function calls in it's own peculiar way, and also newer gcc versions seem to be better at avoiding unnecessary divisions.

Hence it seems to me there are 2 ways to solve the challenge:

1. Do some archaeological work to figure out the exact version of binutils and gcc used to generate the original, and then change the C-code, linkerscript and dtb accordingly.
2. Change big parts of the program to assembly that aligns with the original bootrom.bin so that it also works with newer toolchains.

This solution uses the second approach.

[tmagik]

Here's a hint for option 1.
riscv-software-src/riscv-tools@3921adb

If that is not very close to what built that rom, then I have more software archaeology to do.

[esmil]

Right. If your aim is to understand the code option 1 is better. But if your aim is to verify that the bootrom doesn't contain malicious code I actually think option 2 is a better. I'd much rather read through the bits of assembly I just added and verify that it generates the bootrom with a toolchain I trust, than I'd read some C code, download a special toolchain and then have to read through all that code to check that it doesn't add something extra to generated binary.

[ddevault]

You're never going to attain option 2 nirvana, though. Your suggestion only works if you can take an OOTB risc-v gcc/binutils and compile a binary-perfect copy of the bootloader, but as the target improves and new optimizations are made that's just going to happen less and less often.

[esmil]

You're right that in this pull request the generated zsbl.bin still contain functions compiled from C, and those might change with a future update of gcc that optimizes differently. For now I've tried to keep as many benefits from option 1 as possible, eg. more readable C.

However if this happens you just have switch those functions to assembly like I've done with some of the other functions, and that process has a natural end when every function is switched to assembly, so you're not right that complete option 2 is never going to happen.

[terpstra]

@tmagik All of these changes made to the zsbl.dts are actually correct. The DTS checked into this repository reflects what the U540 would look like if we taped it out again today. However, at the time RTL was finalized, things like the bus-error-unit and the 3rd L2 interrupt did not yet exist. If this repository is intended to reflect the shipped part, we should fix the DTS.

[esmil]

Yes, that's why I replied to @tmagic

Btw. what are the plans with the freedom-u540-c000-bootloader
repository? Are you going to continue development on it and reuse new
versions in other chips, or is it more like a point-in-time code-dump?
If it's the first then I'll refactor my pull request a bit so that
it's easier to keep the "frozen" code for the zsbl burnt into this
first chip separate and continue joint development on both the zsbl
and fsbl for newer chips.

..but I never received any reply before now.