Build for RISC-V with LLVM

Build for RISC-V with LLVM

[Nathaniel Hourt]

Hi, all

I am trying to build u-boot and SPL for my Mars board (riscv, variant of 
the starfive visionfive2) following the board-specific docs [1], using 
LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned 
in [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I 
am not using the cross-compile options; thus my make invocation looks 
like `make HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). 
Note that the chroot I'm building from does not contain gcc/binutils at 
all; LLVM is the only toolchain present.

The build usually succeeds, so I try to pass the SPL to the MaskROM over 
UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No 
output, no response, and I have to reset the board. If I pass a working 
SPL I downloaded, it logs some output then accepts a main u-boot payload 
over UART, so if I send the main u-boot payload I built (u-boot.itb), I 
get a "Load address misaligned" error as in [3].

I attempted to configure my SPL to log to UART by turning on various 
logging options in `menuconfig`, including the options recently 
mentioned by Heinrich Schuchardt in [4], but I have been unsuccessful in 
getting any output from the SPL I built.

So I am looking for guidance. Is building with LLVM/clang (for riscv) 
supported? I don't know what to try next.

Thanks
—
Nathaniel


[1] 
https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
[2] https://docs.u-boot.org/en/latest/build/clang.html
[3] https://pastebin.com/xwEcqEpz
[4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html

Re: Build for RISC-V with LLVM

[Yao Zi]

On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
> Hi, all
> 
> I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
> starfive visionfive2) following the board-specific docs [1], using
> LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
> [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
> using the cross-compile options; thus my make invocation looks like `make
> HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
> chroot I'm building from does not contain gcc/binutils at all; LLVM is the
> only toolchain present.
> 
> The build usually succeeds, so I try to pass the SPL to the MaskROM over
> UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
> output, no response, and I have to reset the board. If I pass a working SPL

Have you tried to apply this patch[1]? U-Boot support for JH7110 is
broken at least in v2025.04 release afaik.

Best regards,
Yao Zi

[1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/

> I downloaded, it logs some output then accepts a main u-boot payload over
> UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
> "Load address misaligned" error as in [3].
> 
> I attempted to configure my SPL to log to UART by turning on various logging
> options in `menuconfig`, including the options recently mentioned by
> Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
> output from the SPL I built.
> 
> So I am looking for guidance. Is building with LLVM/clang (for riscv)
> supported? I don't know what to try next.
> 
> Thanks
> —
> Nathaniel
> 
> 
> [1]
> https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
> [2] https://docs.u-boot.org/en/latest/build/clang.html
> [3] https://pastebin.com/xwEcqEpz
> [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html

Re: Build for RISC-V with LLVM

[Nathaniel]

On Apr 26 2025, at 1:30 am, Yao Zi <ziyao@disroot.org> wrote:
> On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
> > Hi, all
> >
> > I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
> > starfive visionfive2) following the board-specific docs [1], using
> > LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
> > [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
> > using the cross-compile options; thus my make invocation looks like `make
> > HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
> > chroot I'm building from does not contain gcc/binutils at all; LLVM is the
> > only toolchain present.
> >
> > The build usually succeeds, so I try to pass the SPL to the MaskROM over
> > UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
> > output, no response, and I have to reset the board. If I pass a working SPL
>
> Have you tried to apply this patch[1]? U-Boot support for JH7110 is
> broken at least in v2025.04 release afaik.
>
> Best regards,
> Yao Zi
>
> [1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
> > I downloaded, it logs some output then accepts a main u-boot payload over
> > UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
> > "Load address misaligned" error as in [3].
> >
> > I attempted to configure my SPL to log to UART by turning on various logging
> > options in `menuconfig`, including the options recently mentioned by
> > Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
> > output from the SPL I built.
> >
> > So I am looking for guidance. Is building with LLVM/clang (for riscv)
> > supported? I don't know what to try next.
> >
> > Thanks
> > —
> > Nathaniel
> >
> >
> > [1]
> > https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
> > [2] https://docs.u-boot.org/en/latest/build/clang.html
> > [3] https://pastebin.com/xwEcqEpz
> > [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html
>

I just tried the patch, and also pulled latest master, which has that patch by now, but it didn't change the SPL's behavior.
I have heard that I need to be using v2025.01; however, that fails to build for me:
LD lib/efi_loader/boothart_efi.so
ld: error: section type mismatch for .dynamic
>>> <internal>:(.dynamic): SHT_DYNAMIC
>>> output section .text: SHT_PROGBITS
make[2]: *** [scripts/Makefile.lib:539: lib/efi_loader/boothart_efi.so] Error 1
make[1]: *** [scripts/Makefile.build:398: lib/efi_loader] Error 2
make: *** [Makefile:1915: lib] Error 2

I don't understand that error; I'm guessing it's ELF wizardry thus far beyond my ken.
So master builds but doesn't run (at all? there's no output) and going off of [1], wouldn't we expect there to be some output from the SPL when it doesn't work for the known reasons?
v2025.01 doesn't build with my LLVM toolchain, and I'm wondering whether I'm getting actually sane images even when master builds successfully. I have no idea how to verify that... Does anyone know how to analyze the SPL image output, or even what format it's in? Or alternatively, is there a hello world SPL I can build just to test whether I can produce working binaries at all?
Or am I barking up the wrong tree altogether? Ideas welcome. =)
—
Nathaniel

[1] https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/

Re: Build for RISC-V with LLVM

[Yao Zi]

On Sat, Apr 26, 2025 at 06:25:50PM -0500, Nathaniel wrote:
> On Apr 26 2025, at 1:30 am, Yao Zi <ziyao@disroot.org> wrote:
> > On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
> > > Hi, all
> > >
> > > I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
> > > starfive visionfive2) following the board-specific docs [1], using
> > > LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
> > > [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
> > > using the cross-compile options; thus my make invocation looks like `make
> > > HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
> > > chroot I'm building from does not contain gcc/binutils at all; LLVM is the
> > > only toolchain present.
> > >
> > > The build usually succeeds, so I try to pass the SPL to the MaskROM over
> > > UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
> > > output, no response, and I have to reset the board. If I pass a working SPL
> >
> > Have you tried to apply this patch[1]? U-Boot support for JH7110 is
> > broken at least in v2025.04 release afaik.
> >
> > Best regards,
> > Yao Zi
> >
> > [1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
> > > I downloaded, it logs some output then accepts a main u-boot payload over
> > > UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
> > > "Load address misaligned" error as in [3].
> > >
> > > I attempted to configure my SPL to log to UART by turning on various logging
> > > options in `menuconfig`, including the options recently mentioned by
> > > Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
> > > output from the SPL I built.
> > >
> > > So I am looking for guidance. Is building with LLVM/clang (for riscv)
> > > supported? I don't know what to try next.
> > >
> > > Thanks
> > > —
> > > Nathaniel
> > >
> > >
> > > [1]
> > > https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
> > > [2] https://docs.u-boot.org/en/latest/build/clang.html
> > > [3] https://pastebin.com/xwEcqEpz
> > > [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html
> >
> 
> I just tried the patch, and also pulled latest master, which has that patch by now, but it didn't change the SPL's behavior.
> I have heard that I need to be using v2025.01; however, that fails to build for me:
> LD lib/efi_loader/boothart_efi.so
> ld: error: section type mismatch for .dynamic
> >>> <internal>:(.dynamic): SHT_DYNAMIC
> >>> output section .text: SHT_PROGBITS
> make[2]: *** [scripts/Makefile.lib:539: lib/efi_loader/boothart_efi.so] Error 1
> make[1]: *** [scripts/Makefile.build:398: lib/efi_loader] Error 2
> make: *** [Makefile:1915: lib] Error 2

I guess this series[1] (merged between v2025.01 and v2025.04) plays a
role here.

> I don't understand that error; I'm guessing it's ELF wizardry thus far beyond my ken.
> So master builds but doesn't run (at all? there's no output) and going off of [1], wouldn't we expect there to be some output from the SPL when it doesn't work for the known reasons?
> v2025.01 doesn't build with my LLVM toolchain, and I'm wondering whether I'm getting actually sane images even when master builds successfully. I have no idea how to verify that... Does anyone know how to analyze the SPL image output, or even what format it's in? Or alternatively, is there a hello world SPL I can build just to test whether I can produce working binaries at all?
> Or am I barking up the wrong tree altogether? Ideas welcome. =)

I could verify starfive_visionfive2 images built by Clang are broken on
current master branch: seems there's something wrong with Clang when
generating default configuration. Have you seen errors like

	generated_defconfig:33:warning: unexpected data:  # CONFIG_OF_BOARD_FIXUP is not set
	generated_defconfig:34:warning: unexpected data:  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
	generated_defconfig:54:warning: unexpected data:  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
	generated_defconfig:75:warning: unexpected data:  # CONFIG_CMD_BIND is not set
	generated_defconfig:132:warning: unexpected data:  # CONFIG_RAM_SIFIVE is not set
	generated_defconfig:150:warning: unexpected data:  # CONFIG_USB_CDNS3_TI is not set
	generated_defconfig:153:warning: unexpected data:  # CONFIG_WATCHDOG is not set
	generated_defconfig:154:warning: unexpected data:  # CONFIG_WATCHDOG_AUTOSTART is not set

when applying the default configuration? Seems Clang adds some extra
indentation in the preprocessor's output comparing to GCC, which Kconfig
doesn't allow. This breaks the configuration, making SPL unable to find
an appropriate space for stack to use.

With this problem fixed with a dirty patch, I've successfully booted
into U-Boot console with binutils LD. There're still some nasty "out of
memory" errors from EFI subsystem like

	U-Boot 2025.04-01423-g8c9218d0e86c-dirty (Apr 27 2025 - 03:55:20 +0000)

	CPU:   sifive,u74-mc
	Model: StarFive VisionFive 2 v1.3B
	DRAM:  8 GiB
	Core:  159 devices, 29 uclasses, devicetree: board
	WDT:   Not starting watchdog@13070000
	out of memory
	ERROR: Out of memory
	MMC:   mmc@16010000: 0, mmc@16020000: 1
	Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
	*** Warning - bad CRC, using default environment

and images built by LLD are still broken. I'll send a fixing series
after figuring all of these issues out.

For now you could try the dirty fix and see whether console shows up,

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 079add4d5da..ba30652f01a 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -94,6 +94,7 @@ endif

 %_defconfig: $(obj)/conf
        $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
+       $(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
        $(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)

 # Added for U-Boot (backward compatibility)

(the diff format is likely to be broken as it's copied from output of
git diff output, thus cannot be applied directly)

> —
> Nathaniel
> 
> [1] https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/

Best regards,
Yao Zi

[1]: https://lore.kernel.org/u-boot/174364559512.1379294.15546160892706099529.b4-ty@konsulko.com/

Re: Build for RISC-V with LLVM

[Nathaniel Hourt]

On 2025-04-26 23:34, Yao Zi wrote:
> On Sat, Apr 26, 2025 at 06:25:50PM -0500, Nathaniel wrote:
>> On Apr 26 2025, at 1:30 am, Yao Zi <ziyao@disroot.org> wrote:
>> > On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
>> > > Hi, all
>> > >
>> > > I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
>> > > starfive visionfive2) following the board-specific docs [1], using
>> > > LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
>> > > [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
>> > > using the cross-compile options; thus my make invocation looks like `make
>> > > HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
>> > > chroot I'm building from does not contain gcc/binutils at all; LLVM is the
>> > > only toolchain present.
>> > >
>> > > The build usually succeeds, so I try to pass the SPL to the MaskROM over
>> > > UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
>> > > output, no response, and I have to reset the board. If I pass a working SPL
>> >
>> > Have you tried to apply this patch[1]? U-Boot support for JH7110 is
>> > broken at least in v2025.04 release afaik.
>> >
>> > Best regards,
>> > Yao Zi
>> >
>> > [1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
>> > > I downloaded, it logs some output then accepts a main u-boot payload over
>> > > UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
>> > > "Load address misaligned" error as in [3].
>> > >
>> > > I attempted to configure my SPL to log to UART by turning on various logging
>> > > options in `menuconfig`, including the options recently mentioned by
>> > > Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
>> > > output from the SPL I built.
>> > >
>> > > So I am looking for guidance. Is building with LLVM/clang (for riscv)
>> > > supported? I don't know what to try next.
>> > >
>> > > Thanks
>> > > —
>> > > Nathaniel
>> > >
>> > >
>> > > [1]
>> > > https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
>> > > [2] https://docs.u-boot.org/en/latest/build/clang.html
>> > > [3] https://pastebin.com/xwEcqEpz
>> > > [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html
>> >
>> 
>> I just tried the patch, and also pulled latest master, which has that 
>> patch by now, but it didn't change the SPL's behavior.
>> I have heard that I need to be using v2025.01; however, that fails to 
>> build for me:
>> LD lib/efi_loader/boothart_efi.so
>> ld: error: section type mismatch for .dynamic
>> >>> <internal>:(.dynamic): SHT_DYNAMIC
>> >>> output section .text: SHT_PROGBITS
>> make[2]: *** [scripts/Makefile.lib:539: 
>> lib/efi_loader/boothart_efi.so] Error 1
>> make[1]: *** [scripts/Makefile.build:398: lib/efi_loader] Error 2
>> make: *** [Makefile:1915: lib] Error 2
> 
> I guess this series[1] (merged between v2025.01 and v2025.04) plays a
> role here.
> 
>> I don't understand that error; I'm guessing it's ELF wizardry thus far 
>> beyond my ken.
>> So master builds but doesn't run (at all? there's no output) and going 
>> off of [1], wouldn't we expect there to be some output from the SPL 
>> when it doesn't work for the known reasons?
>> v2025.01 doesn't build with my LLVM toolchain, and I'm wondering 
>> whether I'm getting actually sane images even when master builds 
>> successfully. I have no idea how to verify that... Does anyone know 
>> how to analyze the SPL image output, or even what format it's in? Or 
>> alternatively, is there a hello world SPL I can build just to test 
>> whether I can produce working binaries at all?
>> Or am I barking up the wrong tree altogether? Ideas welcome. =)
> 
> I could verify starfive_visionfive2 images built by Clang are broken on
> current master branch: seems there's something wrong with Clang when
> generating default configuration. Have you seen errors like
> 
> 	generated_defconfig:33:warning: unexpected data:  # 
> CONFIG_OF_BOARD_FIXUP is not set
> 	generated_defconfig:34:warning: unexpected data:  # 
> CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> 	generated_defconfig:54:warning: unexpected data:  # 
> CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> 	generated_defconfig:75:warning: unexpected data:  # CONFIG_CMD_BIND is 
> not set
> 	generated_defconfig:132:warning: unexpected data:  # CONFIG_RAM_SIFIVE 
> is not set
> 	generated_defconfig:150:warning: unexpected data:  # 
> CONFIG_USB_CDNS3_TI is not set
> 	generated_defconfig:153:warning: unexpected data:  # CONFIG_WATCHDOG 
> is not set
> 	generated_defconfig:154:warning: unexpected data:  # 
> CONFIG_WATCHDOG_AUTOSTART is not set
> 
> when applying the default configuration? Seems Clang adds some extra
> indentation in the preprocessor's output comparing to GCC, which 
> Kconfig
> doesn't allow. This breaks the configuration, making SPL unable to find
> an appropriate space for stack to use.
> 
> With this problem fixed with a dirty patch, I've successfully booted
> into U-Boot console with binutils LD. There're still some nasty "out of
> memory" errors from EFI subsystem like
> 
> 	U-Boot 2025.04-01423-g8c9218d0e86c-dirty (Apr 27 2025 - 03:55:20 
> +0000)
> 
> 	CPU:   sifive,u74-mc
> 	Model: StarFive VisionFive 2 v1.3B
> 	DRAM:  8 GiB
> 	Core:  159 devices, 29 uclasses, devicetree: board
> 	WDT:   Not starting watchdog@13070000
> 	out of memory
> 	ERROR: Out of memory
> 	MMC:   mmc@16010000: 0, mmc@16020000: 1
> 	Loading Environment from SPIFlash... SF: Detected gd25lq128 with page 
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> 	*** Warning - bad CRC, using default environment
> 
> and images built by LLD are still broken. I'll send a fixing series
> after figuring all of these issues out.
> 
> For now you could try the dirty fix and see whether console shows up,
> 
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 079add4d5da..ba30652f01a 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -94,6 +94,7 @@ endif
> 
>  %_defconfig: $(obj)/conf
>         $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x 
> assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o 
> generated_defconfig
> +       $(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
>         $(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
> 
>  # Added for U-Boot (backward compatibility)
> 
> (the diff format is likely to be broken as it's copied from output of
> git diff output, thus cannot be applied directly)
> 
>> —
>> Nathaniel
>> 
>> [1] 
>> https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
> 
> Best regards,
> Yao Zi
> 
> [1]: 
> https://lore.kernel.org/u-boot/174364559512.1379294.15546160892706099529.b4-ty@konsulko.com/

I don't recall ever seeing the config warnings, and my config has no 
lines with leading spaces. I've gone ahead and patched my local clang to 
eliminate the leading space issue anyways, since that seems the 
appropriate place to resolve the issue.

I've also applied your second patch [1] to eliminate the gd issue, and I 
have Heinrich Schuchardt's pllclk patch as well.

I do not get any console this way — unfortunately there is still no 
output from the SPL, but that is likely due to my use of LLD.

Do you have any further information on the issue of linking with LLD? Is 
anything more known about this problem yet?

[1] https://lists.denx.de/pipermail/u-boot/2025-April/588038.html

—
Nathaniel

Re: Build for RISC-V with LLVM

[Yao Zi]

On Thu, May 01, 2025 at 03:54:34PM -0500, Nathaniel Hourt wrote:
> On 2025-04-26 23:34, Yao Zi wrote:
> > On Sat, Apr 26, 2025 at 06:25:50PM -0500, Nathaniel wrote:
> > > On Apr 26 2025, at 1:30 am, Yao Zi <ziyao@disroot.org> wrote:
> > > > On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
> > > > > Hi, all
> > > > >
> > > > > I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
> > > > > starfive visionfive2) following the board-specific docs [1], using
> > > > > LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
> > > > > [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
> > > > > using the cross-compile options; thus my make invocation looks like `make
> > > > > HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
> > > > > chroot I'm building from does not contain gcc/binutils at all; LLVM is the
> > > > > only toolchain present.
> > > > >
> > > > > The build usually succeeds, so I try to pass the SPL to the MaskROM over
> > > > > UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
> > > > > output, no response, and I have to reset the board. If I pass a working SPL
> > > >
> > > > Have you tried to apply this patch[1]? U-Boot support for JH7110 is
> > > > broken at least in v2025.04 release afaik.
> > > >
> > > > Best regards,
> > > > Yao Zi
> > > >
> > > > [1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
> > > > > I downloaded, it logs some output then accepts a main u-boot payload over
> > > > > UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
> > > > > "Load address misaligned" error as in [3].
> > > > >
> > > > > I attempted to configure my SPL to log to UART by turning on various logging
> > > > > options in `menuconfig`, including the options recently mentioned by
> > > > > Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
> > > > > output from the SPL I built.
> > > > >
> > > > > So I am looking for guidance. Is building with LLVM/clang (for riscv)
> > > > > supported? I don't know what to try next.
> > > > >
> > > > > Thanks
> > > > > —
> > > > > Nathaniel
> > > > >
> > > > >
> > > > > [1]
> > > > > https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
> > > > > [2] https://docs.u-boot.org/en/latest/build/clang.html
> > > > > [3] https://pastebin.com/xwEcqEpz
> > > > > [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html
> > > >
> > > 
> > > I just tried the patch, and also pulled latest master, which has
> > > that patch by now, but it didn't change the SPL's behavior.
> > > I have heard that I need to be using v2025.01; however, that fails
> > > to build for me:
> > > LD lib/efi_loader/boothart_efi.so
> > > ld: error: section type mismatch for .dynamic
> > > >>> <internal>:(.dynamic): SHT_DYNAMIC
> > > >>> output section .text: SHT_PROGBITS
> > > make[2]: *** [scripts/Makefile.lib:539:
> > > lib/efi_loader/boothart_efi.so] Error 1
> > > make[1]: *** [scripts/Makefile.build:398: lib/efi_loader] Error 2
> > > make: *** [Makefile:1915: lib] Error 2
> > 
> > I guess this series[1] (merged between v2025.01 and v2025.04) plays a
> > role here.
> > 
> > > I don't understand that error; I'm guessing it's ELF wizardry thus
> > > far beyond my ken.
> > > So master builds but doesn't run (at all? there's no output) and
> > > going off of [1], wouldn't we expect there to be some output from
> > > the SPL when it doesn't work for the known reasons?
> > > v2025.01 doesn't build with my LLVM toolchain, and I'm wondering
> > > whether I'm getting actually sane images even when master builds
> > > successfully. I have no idea how to verify that... Does anyone know
> > > how to analyze the SPL image output, or even what format it's in? Or
> > > alternatively, is there a hello world SPL I can build just to test
> > > whether I can produce working binaries at all?
> > > Or am I barking up the wrong tree altogether? Ideas welcome. =)
> > 
> > I could verify starfive_visionfive2 images built by Clang are broken on
> > current master branch: seems there's something wrong with Clang when
> > generating default configuration. Have you seen errors like
> > 
> > 	generated_defconfig:33:warning: unexpected data:  #
> > CONFIG_OF_BOARD_FIXUP is not set
> > 	generated_defconfig:34:warning: unexpected data:  #
> > CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > 	generated_defconfig:54:warning: unexpected data:  #
> > CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > 	generated_defconfig:75:warning: unexpected data:  # CONFIG_CMD_BIND is
> > not set
> > 	generated_defconfig:132:warning: unexpected data:  # CONFIG_RAM_SIFIVE
> > is not set
> > 	generated_defconfig:150:warning: unexpected data:  #
> > CONFIG_USB_CDNS3_TI is not set
> > 	generated_defconfig:153:warning: unexpected data:  # CONFIG_WATCHDOG is
> > not set
> > 	generated_defconfig:154:warning: unexpected data:  #
> > CONFIG_WATCHDOG_AUTOSTART is not set
> > 
> > when applying the default configuration? Seems Clang adds some extra
> > indentation in the preprocessor's output comparing to GCC, which Kconfig
> > doesn't allow. This breaks the configuration, making SPL unable to find
> > an appropriate space for stack to use.
> > 
> > With this problem fixed with a dirty patch, I've successfully booted
> > into U-Boot console with binutils LD. There're still some nasty "out of
> > memory" errors from EFI subsystem like
> > 
> > 	U-Boot 2025.04-01423-g8c9218d0e86c-dirty (Apr 27 2025 - 03:55:20 +0000)
> > 
> > 	CPU:   sifive,u74-mc
> > 	Model: StarFive VisionFive 2 v1.3B
> > 	DRAM:  8 GiB
> > 	Core:  159 devices, 29 uclasses, devicetree: board
> > 	WDT:   Not starting watchdog@13070000
> > 	out of memory
> > 	ERROR: Out of memory
> > 	MMC:   mmc@16010000: 0, mmc@16020000: 1
> > 	Loading Environment from SPIFlash... SF: Detected gd25lq128 with page
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > 	*** Warning - bad CRC, using default environment
> > 
> > and images built by LLD are still broken. I'll send a fixing series
> > after figuring all of these issues out.
> > 
> > For now you could try the dirty fix and see whether console shows up,
> > 
> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> > index 079add4d5da..ba30652f01a 100644
> > --- a/scripts/kconfig/Makefile
> > +++ b/scripts/kconfig/Makefile
> > @@ -94,6 +94,7 @@ endif
> > 
> >  %_defconfig: $(obj)/conf
> >         $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x
> > assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o
> > generated_defconfig
> > +       $(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
> >         $(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
> > 
> >  # Added for U-Boot (backward compatibility)
> > 
> > (the diff format is likely to be broken as it's copied from output of
> > git diff output, thus cannot be applied directly)
> > 
> > > —
> > > Nathaniel
> > > 
> > > [1] https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
> > 
> > Best regards,
> > Yao Zi
> > 
> > [1]: https://lore.kernel.org/u-boot/174364559512.1379294.15546160892706099529.b4-ty@konsulko.com/
> 
> I don't recall ever seeing the config warnings, and my config has no lines
> with leading spaces. I've gone ahead and patched my local clang to eliminate
> the leading space issue anyways, since that seems the appropriate place to
> resolve the issue.
> 
> I've also applied your second patch [1] to eliminate the gd issue, and I
> have Heinrich Schuchardt's pllclk patch as well.
> 
> I do not get any console this way — unfortunately there is still no output
> from the SPL, but that is likely due to my use of LLD.
> 
> 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

Re: Build for RISC-V with LLVM

[Nathaniel Hourt]

On 2025-05-01 20:48, Yao Zi wrote:
> On Thu, May 01, 2025 at 03:54:34PM -0500, Nathaniel Hourt wrote:
>> On 2025-04-26 23:34, Yao Zi wrote:
>> > On Sat, Apr 26, 2025 at 06:25:50PM -0500, Nathaniel wrote:
>> > > On Apr 26 2025, at 1:30 am, Yao Zi <ziyao@disroot.org> wrote:
>> > > > On Fri, Apr 25, 2025 at 12:43:08PM -0500, Nathaniel Hourt wrote:
>> > > > > Hi, all
>> > > > >
>> > > > > I am trying to build u-boot and SPL for my Mars board (riscv, variant of the
>> > > > > starfive visionfive2) following the board-specific docs [1], using
>> > > > > LLVM/clang as my toolchain with the HOSTCC and CC make options mentioned in
>> > > > > [2]. I'm building from a RISC-V native chroot using qemu-binfmt so I am not
>> > > > > using the cross-compile options; thus my make invocation looks like `make
>> > > > > HOSTCC=clang CC=clang` (for OpenSBI, I just pass 'LLVM=1'). Note that the
>> > > > > chroot I'm building from does not contain gcc/binutils at all; LLVM is the
>> > > > > only toolchain present.
>> > > > >
>> > > > > The build usually succeeds, so I try to pass the SPL to the MaskROM over
>> > > > > UART (using the u-boot-spl.bin.normal.out image) and it just hangs. No
>> > > > > output, no response, and I have to reset the board. If I pass a working SPL
>> > > >
>> > > > Have you tried to apply this patch[1]? U-Boot support for JH7110 is
>> > > > broken at least in v2025.04 release afaik.
>> > > >
>> > > > Best regards,
>> > > > Yao Zi
>> > > >
>> > > > [1]: https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
>> > > > > I downloaded, it logs some output then accepts a main u-boot payload over
>> > > > > UART, so if I send the main u-boot payload I built (u-boot.itb), I get a
>> > > > > "Load address misaligned" error as in [3].
>> > > > >
>> > > > > I attempted to configure my SPL to log to UART by turning on various logging
>> > > > > options in `menuconfig`, including the options recently mentioned by
>> > > > > Heinrich Schuchardt in [4], but I have been unsuccessful in getting any
>> > > > > output from the SPL I built.
>> > > > >
>> > > > > So I am looking for guidance. Is building with LLVM/clang (for riscv)
>> > > > > supported? I don't know what to try next.
>> > > > >
>> > > > > Thanks
>> > > > > —
>> > > > > Nathaniel
>> > > > >
>> > > > >
>> > > > > [1]
>> > > > > https://docs.u-boot.org/en/latest/board/starfive/milk-v_mars.html#milk-v-mars
>> > > > > [2] https://docs.u-boot.org/en/latest/build/clang.html
>> > > > > [3] https://pastebin.com/xwEcqEpz
>> > > > > [4] https://lists.denx.de/pipermail/u-boot/2025-April/586264.html
>> > > >
>> > >
>> > > I just tried the patch, and also pulled latest master, which has
>> > > that patch by now, but it didn't change the SPL's behavior.
>> > > I have heard that I need to be using v2025.01; however, that fails
>> > > to build for me:
>> > > LD lib/efi_loader/boothart_efi.so
>> > > ld: error: section type mismatch for .dynamic
>> > > >>> <internal>:(.dynamic): SHT_DYNAMIC
>> > > >>> output section .text: SHT_PROGBITS
>> > > make[2]: *** [scripts/Makefile.lib:539:
>> > > lib/efi_loader/boothart_efi.so] Error 1
>> > > make[1]: *** [scripts/Makefile.build:398: lib/efi_loader] Error 2
>> > > make: *** [Makefile:1915: lib] Error 2
>> >
>> > I guess this series[1] (merged between v2025.01 and v2025.04) plays a
>> > role here.
>> >
>> > > I don't understand that error; I'm guessing it's ELF wizardry thus
>> > > far beyond my ken.
>> > > So master builds but doesn't run (at all? there's no output) and
>> > > going off of [1], wouldn't we expect there to be some output from
>> > > the SPL when it doesn't work for the known reasons?
>> > > v2025.01 doesn't build with my LLVM toolchain, and I'm wondering
>> > > whether I'm getting actually sane images even when master builds
>> > > successfully. I have no idea how to verify that... Does anyone know
>> > > how to analyze the SPL image output, or even what format it's in? Or
>> > > alternatively, is there a hello world SPL I can build just to test
>> > > whether I can produce working binaries at all?
>> > > Or am I barking up the wrong tree altogether? Ideas welcome. =)
>> >
>> > I could verify starfive_visionfive2 images built by Clang are broken on
>> > current master branch: seems there's something wrong with Clang when
>> > generating default configuration. Have you seen errors like
>> >
>> > 	generated_defconfig:33:warning: unexpected data:  #
>> > CONFIG_OF_BOARD_FIXUP is not set
>> > 	generated_defconfig:34:warning: unexpected data:  #
>> > CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>> > 	generated_defconfig:54:warning: unexpected data:  #
>> > CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>> > 	generated_defconfig:75:warning: unexpected data:  # CONFIG_CMD_BIND is
>> > not set
>> > 	generated_defconfig:132:warning: unexpected data:  # CONFIG_RAM_SIFIVE
>> > is not set
>> > 	generated_defconfig:150:warning: unexpected data:  #
>> > CONFIG_USB_CDNS3_TI is not set
>> > 	generated_defconfig:153:warning: unexpected data:  # CONFIG_WATCHDOG is
>> > not set
>> > 	generated_defconfig:154:warning: unexpected data:  #
>> > CONFIG_WATCHDOG_AUTOSTART is not set
>> >
>> > when applying the default configuration? Seems Clang adds some extra
>> > indentation in the preprocessor's output comparing to GCC, which Kconfig
>> > doesn't allow. This breaks the configuration, making SPL unable to find
>> > an appropriate space for stack to use.
>> >
>> > With this problem fixed with a dirty patch, I've successfully booted
>> > into U-Boot console with binutils LD. There're still some nasty "out of
>> > memory" errors from EFI subsystem like
>> >
>> > 	U-Boot 2025.04-01423-g8c9218d0e86c-dirty (Apr 27 2025 - 03:55:20 +0000)
>> >
>> > 	CPU:   sifive,u74-mc
>> > 	Model: StarFive VisionFive 2 v1.3B
>> > 	DRAM:  8 GiB
>> > 	Core:  159 devices, 29 uclasses, devicetree: board
>> > 	WDT:   Not starting watchdog@13070000
>> > 	out of memory
>> > 	ERROR: Out of memory
>> > 	MMC:   mmc@16010000: 0, mmc@16020000: 1
>> > 	Loading Environment from SPIFlash... SF: Detected gd25lq128 with page
>> > size 256 Bytes, erase size 4 KiB, total 16 MiB
>> > 	*** Warning - bad CRC, using default environment
>> >
>> > and images built by LLD are still broken. I'll send a fixing series
>> > after figuring all of these issues out.
>> >
>> > For now you could try the dirty fix and see whether console shows up,
>> >
>> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> > index 079add4d5da..ba30652f01a 100644
>> > --- a/scripts/kconfig/Makefile
>> > +++ b/scripts/kconfig/Makefile
>> > @@ -94,6 +94,7 @@ endif
>> >
>> >  %_defconfig: $(obj)/conf
>> >         $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x
>> > assembler-with-cpp $(srctree)/arch/$(SRCARCH)/configs/$@ -o
>> > generated_defconfig
>> > +       $(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
>> >         $(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
>> >
>> >  # Added for U-Boot (backward compatibility)
>> >
>> > (the diff format is likely to be broken as it's copied from output of
>> > git diff output, thus cannot be applied directly)
>> >
>> > > —
>> > > Nathaniel
>> > >
>> > > [1] https://lore.kernel.org/all/20250330162421.238483-1-heinrich.schuchardt@canonical.com/
>> >
>> > Best regards,
>> > Yao Zi
>> >
>> > [1]: https://lore.kernel.org/u-boot/174364559512.1379294.15546160892706099529.b4-ty@konsulko.com/
>> 
>> I don't recall ever seeing the config warnings, and my config has no 
>> lines
>> with leading spaces. I've gone ahead and patched my local clang to 
>> eliminate
>> the leading space issue anyways, since that seems the appropriate 
>> place to
>> resolve the issue.
>> 
>> I've also applied your second patch [1] to eliminate the gd issue, and 
>> I
>> have Heinrich Schuchardt's pllclk patch as well.
>> 
>> I do not get any console this way — unfortunately there is still no 
>> output
>> from the SPL, but that is likely due to my use of LLD.
>> 
>> 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

Re: 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

Re: Build for RISC-V with LLVM

[Yao Zi]

On Wed, Nov 05, 2025 at 10:26:56PM -0600, Nathaniel Hourt wrote:
> 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! =)

Wow, exciting update!

> 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.

...

> 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.)

I suspect this doesn't affect RISC-V boards enabling OF_BOARD, since we
have a default board_fdt_blob_setup() in arch/riscv/lib/board.c, which
retrieves the FDT address passed by SBI, thus it doesn't matter whether
fdt_find_separate() succeeds or not.

starfive_visionfive2_defconfig does enable OF_BOARD, so it isn't a
problem. But for other ports, it's necessary to correctly pad the binary
to the alignment enforced for __image_binary_end/__bss_end. What ports
did you observe issues on without padding?

> 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?

I don't think so.

Currently RISC-V SPL works in, at least to me, a crazy way. Both proper
U-Boot and SPL for RISC-V are now compiled with -fpic flags, which means
GOT relocations could be generated, and we need a GOT for these
relocations to work.

We don't have any code in SPL to fill the GOT table, but linkers could
fill it for us if address of the symbol is determinate at link time,
which covers basically all symbols for a static executable.

But back to the original question, why should we compile SPL with -fpic
(see arch/riscv/config.mk) in the first place, and thus (maybe[1]) need
a GOT? In the current way, SPL won't work, either if it's loaded in an
address differing from CONFIG_SPL_TEXT_BASE, because symbols won't stay
in the address specified and pre-filled by the linker.

So compiling SPL with -fno-pic sounds more reasonable to me, and though
I couldn't test it now, it should fix the boot issue with
starfive_visionfive2_defconfig and ld.lld, too. This would be a huge
change to RISC-V port, and I think deserves more discussion.

> 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!

Many thanks for digging into it.

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

Regards,
Yao Zi

[1]: Technically for a static binary, we could lower all GOT relocations
to pcrel ones, and thus it could run anywhere and require no GOT. But
during my experiment, even building starfive_visionfive2_defconfig with
ld.bfd still generates a GOT with -fpic in arch/riscv/config.mk changed
to -fpie, and "la" pseudo-instructions in arch/riscv/start.S replaced
with "lla". Not sure whether I missed something.

Re: Build for RISC-V with LLVM

[Nathaniel Hourt]

On 2025-11-06 04:29, Yao Zi wrote:
> [...]
> But for other ports, it's necessary to correctly pad the binary
> to the alignment enforced for __image_binary_end/__bss_end. What ports
> did you observe issues on without padding?
> [...]

Only on a Milk-V Megrez board, which is an ESWIN EIC7700X SoC and as 
such, I believe it is not actually supported by upstream u-boot. The 
downstream repo [1] that supports it forked off quite some time ago, and 
thus may not be relevant here... Nevertheless, it also breaks when using 
LLD, because the u-boot-nodtb.bin is not 8-byte-aligned. If I pad it 
with null bytes to the 8-byte position that _end points to and then 
manually concatenate the DTB, it boots up and runs great.

I note that on that board, U-Boot does not have an SPL and is instead 
deployed as a payload of OpenSBI.

[1] https://github.com/milkv-megrez/rockos-u-boot

I suppose I also should've mentioned in my earlier email, I am now 
successfully building and running U-Boot built with Clang and LLD using 
Clang's integrated assembler instead of GNU as and using LLVM's binutils 
for, i.e., objcopy:

> Hit any key to stop autoboot: 0
> StarFive # version
> U-Boot 2025.10-pylon-00761-gc2104da88367-dirty (Nov 06 2025 - 02:03:37 
> +0000)
> 
> clang version 20.1.7+libcxx
> LLD 20.1.7 (compatible with GNU linkers)
> StarFive #

This is what I set out to do, so I am quite excited. =)

Is there anything else I can do to help get this issue properly resolved 
in the code so builds Just Work?

—
Nathaniel