From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CA66EC369DC for ; Fri, 2 May 2025 01:48:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E63938059D; Fri, 2 May 2025 03:48:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=disroot.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; secure) header.d=disroot.org header.i=@disroot.org header.b="CQswPjwT"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 23EB580F03; Fri, 2 May 2025 03:48:50 +0200 (CEST) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 69B88803CC for ; Fri, 2 May 2025 03:48:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=disroot.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ziyao@disroot.org Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 0AC6825EF5; Fri, 2 May 2025 03:48:47 +0200 (CEST) Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id v4NP55zJtZA6; Fri, 2 May 2025 03:48:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1746150525; bh=Ko7RD0uZea3L685h+Mvz/Cg6Vhlt7fppxObST8nCkLw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=CQswPjwTeBFsWN6y1pxDEqRGoqrU4GgjQap/1379QgEFjcKG2/z6qFUXKVgIEMpP/ dpi9BcGgxbcZtxpbuVqNT50ev4JoSvfy1MNPM7UDzuJ0Z4c5m9b0ak9HXF2krK/zg2 mCNJ+X4tq3DT2SRagi686QAcoSjsMdVMknXYS9L9AmYXuR/Lgr5ObHC5iQB1AM15wb mkFJQm7qDEK8W1NqJEUOkIKsSy4/Eb0QF+74vexK9zC0yOpKvm3fR7+0nCxO35CiQ4 K/q2XXD2hYbjCwAcqf+GN6LyzuKtl7ezIwMbiaWPtjJe89v2eUQ4IXPFJKLISZxXGK zwTDnskvNm+Tg== Date: Fri, 2 May 2025 01:48:28 +0000 From: Yao Zi To: Nathaniel Hourt Cc: UBML Subject: Re: Build for RISC-V with LLVM Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean 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 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 > > > >>> :(.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