Build for RISC-V with LLVM

[Nathaniel Hourt]

On 2025-05-01 21:31, Nathaniel Hourt wrote:

> On 2025-05-01 20:48, Yao Zi wrote: On Thu, May 01, 2025 at 03:54:34PM 
> -0500, Nathaniel Hourt wrote: Do you have any further information on 
> the issue of linking with LLD? Is
> anything more known about this problem yet?
> Sadly no, without any serial output it's hard to work on the problem 
> and
> I haven't searched through the mailing list for similar reports.
> Additionally, I don't have enough time to dig further on the issue...
> sorry about it.
> 
> I could revisit the linking problem sometime later if it's still there.
> May you give ld.bfd a try for now?
> 
> [1] https://lists.denx.de/pipermail/u-boot/2025-April/588038.html
> 
> --
> Nathaniel
> Thanks,
> Yao Zi

Oh, it's certainly an option. =)

But it'll be more fun to dig in and see if I can get lucky enough to 
figure out why LLD isn't doing the job correctly. I suppose I'll start 
by trying to figure out from the make system how the SPL image is 
derived and begin analyzing it or the build assets from which it is 
derived to determine what might be going wrong.

Advice and pointers are always welcome!

--
Nathaniel
I have found the problem and ~~fixed~~ worked around it! =)

So let's dig in. The problem is, when we link with LLD, the FDT winds up 
in the wrong place and U-Boot/SPL can't find it.

Now, I'm not completely certain this is the code the SPL runs to find 
the FDT, but I'm betting it's close enough:
lib/fdtdec.c, function fdt_find_separate [1]
```

#ifdef CONFIG_XPL_BUILD
  /* FDT is at end of BSS unless it is in a different memory region */
  if (CONFIG_IS_ENABLED(SEPARATE_BSS))
  fdt_blob = (ulong *)_image_binary_end;
  else
  fdt_blob = (ulong *)__bss_end;
#else
  /* FDT is at end of image */
  fdt_blob = (ulong *)_end;

  if (_DEBUG && !fdtdec_prepare_fdt(fdt_blob)) {
```

So it's looking for the FDT at the end. I do have 
CONFIG_SPL_SEPARATE_BSS=y (default, I think; I haven't touched it) so 
SPL is probably looking for the FDT at _image_binary_end, and main uboot 
at _end. Now, if we make with V=1, we see that both the SPL and main 
uboot have a step like:
`cat u-boot-spl-nodtb.bin u-boot-spl.dtb > u-boot-spl-dtb.bin`
...and this is then used to generate the final images. So the code is 
expecting to load the FDT from the end, and the build is using a simple 
cat to put it there.

If this works as it should, we should find that the base address of the 
SPL/uboot image, plus the size of that -nodtb.bin, will give us the 
address of the _end marker that the code is using to find the FDT. And 
with ld.bfd, indeed it does! But with ld.lld...
The SPL base address is 0x8000000 and _image_binary_end is 0x80248fc, so 
we expect the size of u-boot-spl-nodtb.bin to be exactly 0x248fc bytes; 
however, mine is 0x24a98, which is too large! If we concatenate the FDT, 
it'll wind up 412 bytes beyond where the code looks for it, and the SPL 
will fail.

The main uboot payload will also fail with a mismatch, because although 
the fdt very nearly hits the right spot, it actually lands 3 bytes early 
because u-boot-nofdt.bin is not 8-byte aligned:
$ grep "\b_end" u-boot.map

         402c9cb0         402c9cb0        0     1 _end = .

$ grep "\b_start" u-boot.map

         40200000         40200000        0     1                 _start
$ printf "%x\n" `du -b u-boot-nodtb.bin | cut -f1`

c9cad

(Actually, the main uboot seems to be working on the starfive now, even 
with this misalignment, but it wasn't back in May... Nevertheless, this 
issue does still seem to affect other boards, particularly one I have 
which doesn't use an SPL. Padding those last 3 bytes with nulls fixes 
it.)

Alright, so focusing back on the SPL... Why is the -nofdtb image too 
long? Well, let's look in the vicinity:
$ grep 8024 spl/u-boot-spl.map | tail -n5
          80248fc          80248fc        0     1 _end = .
          80248fc          80248fc        0     1 _image_binary_end = .
          80248fc          80248fc        0     1 __image_copy_end = .
          8024900          8024900      198     8 .got
         8024900          8024900      198     8         
<internal>:(.got)
Hmmm, for some reason, LLD is putting the GOT after the end tag. Should 
the SPL even _have_ a GOT?

So at last, here is my workaround:
diff --git a/arch/riscv/cpu/u-boot-spl.lds 
b/arch/riscv/cpu/u-boot-spl.lds
index 0717833df55..6e30f2f26dc 100644
--- a/arch/riscv/cpu/u-boot-spl.lds
+++ b/arch/riscv/cpu/u-boot-spl.lds
@@ -33,6 +33,14 @@ SECTIONS
         } > .spl_mem
         . = ALIGN(4);

+       .got : {
+               __got_start = .;
+               *(.got.plt) *(.got)
+               __got_end = .;
+       } > .spl_mem
+
+       . = ALIGN(4);
+
         __u_boot_list : {
                 KEEP(*(SORT(__u_boot_list*)));
         } > .spl_mem

Explicitly position the GOT the same place the main uboot image keeps 
it, so it doesn't sneak in somewhere it shouldn't.

Now, I'm sure this is not a proper solution (I note that 
u-boot-nodtb.bin is still wrong), but I have no idea what a proper 
solution would be, nor do I really know exactly what is going wrong here 
at all. But I've found a way to get everything running, and I hope I've 
found enough that someone who _does_ know what they're doing can see the 
real problem and how to fix it. =)

OK, that's all I've got!

-- 
Nathaniel

Links:
------
[1] 
https://source.denx.de/u-boot/u-boot/-/blob/master/lib/fdtdec.c#L1250