On 12/2/25 08:03, Icenowy Zheng wrote:
在 2025-12-02星期二的 07:15 +0100,Heinrich Schuchardt写道:
On 12/2/25 06:28, Icenowy Zheng wrote:
在 2025-12-02星期二的 03:57 +0000,Yao Zi写道:
On Mon, Dec 01, 2025 at 06:49:03PM +0100, Heinrich Schuchardt
wrote:
The following functions are provided:

Count leading zero bits

* int __clzsi2 (unsigned int a)
* int __clzdi2 (unsigned long a)
* int __clzti2 (unsigned long long a)

Count trailing zero bits

* int __ctzsi2 (unsigned int a)
* int __ctzdi2 (unsigned long a)
* int __ctzti2 (unsigned long long a)

Signed-off-by: Heinrich Schuchardt
<[email protected]>
---

I noted there's another series with the same subject[1] sent
almost
at
the same time, and I couldn't tell the difference at the first
glance.
Is this an incident?

   arch/Kconfig            |   1 +
   arch/riscv/lib/Makefile |   2 +
   arch/riscv/lib/clz.c    | 105
++++++++++++++++++++++++++++++++++++++++
   arch/riscv/lib/ctz.c    |  95
++++++++++++++++++++++++++++++++++++
   lib/Kconfig             |   2 +-
   5 files changed, 204 insertions(+), 1 deletion(-)
   create mode 100644 arch/riscv/lib/clz.c
   create mode 100644 arch/riscv/lib/ctz.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 3133f892f94..4af0da2485f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -159,6 +159,7 @@ config PPC
   config RISCV
          bool "RISC-V architecture"
          select CREATE_ARCH_SYMLINK
+       select HAVE_PRIVATE_LIBGCC if 64BIT

Are 32-bit platforms excluded for lacking of enough library
functions?

Yes. See
https://lore.kernel.org/u-boot/[email protected]/T/#mbf44c9f5073649bbf2e1368ffbeaec82680a268d

Should we exclude !RISCV_ISA_F || !RISCV_ISA_D platforms as well?
Though

libgcc.a as provided by distros assumes that you have the D and F
extensions. Either a specific libgcc.a will be needed or we will have
to
implement the missing functions in the private lib if such platforms.

It would make more sense to set CONFIG_USE_PRIVATE_LIBGCC=n for such
platforms than setting CONFIG_HAVE_PRIVATE_LIBGCC=n.

Which way we want to go can be decided when such platforms arrive.

there's no in-tree 64-bit port without F/D extension.

The S7 core in U74-MC complex seems to have only IMAC, no F/D.
The S7 core is not supported by U-Boot.

https://starfivetech.com/uploads/u74_core_complex_manual_21G1.pdf
talks of U7 and has "The U7 FPU provides full hardware support for the IEEE 754-2008 floating-point standard for 32-bit single-precision and 64-bit double-precision arithmetic."

https://www.sifive.com/document-file/freedom-u740-c000-manual mentions: "The S7 RISC‑V Core supports the RV64IMAC extension string."

The main user of floating point variables in U-Boot is the TrueType library. I guess without TrueType you will not be using the floating point unit


Well at least SPL is run on the S7 cores, although the SBI should keep
the S7 core from being running main U-Boot.

On the Unmatched board the HSM extension reports the S7 hart of the Unmatched board as stopped.

Harts:
  0: stopped
  1: started
  2: stopped
  3: stopped
  4: stopped

But it seems that the SBI API does not allow to determine if a hart actually has entered OpenSBI.

qemu-riscv64_smode_defconfig can be booted with
-cpu rv64,zfa=off,f=off,d=off

Best regards

Heinrich


          select HAVE_SETJMP
          select HAVE_INITJMP
          select SUPPORT_ACPI

Regards,
Yao Zi

[1]:
https://lore.kernel.org/u-boot/[email protected]/




Reply via email to