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 <zi...@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.schucha...@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.schucha...@canonical.com/
>
> Best regards,
> Yao Zi
>
> [1]:
https://lore.kernel.org/u-boot/174364559512.1379294.15546160892706099529.b4...@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?
