On 10/17/25 03:33, Yao Zi wrote:
On Thu, Oct 16, 2025 at 07:04:48PM +0200, Heinrich Schuchardt wrote:
On 10/16/25 18:58, Heinrich Schuchardt wrote:
Commit a681cfecb434 ("riscv: Add a Zalrsc-only alternative for
synchronization in start.S") changed the hart synchronization in start.S.
It uses CONFIG_IS_ENABLED(RISCV_ISA_ZAAMO) to determine which method to
use. If the macro evaluates to true the old behavior is maintained.
The macro evaluates to false for SPL builds which was unintended. Use
IS_ENABLED(CONFIG_RISCV_ISA_ZAAMO) instead.
This fixes a boot failure on StarFive JH7110 based boards.
Fixes: a681cfecb434 ("riscv: Add a Zalrsc-only alternative for synchronization in
start.S")
Reported-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
e6646b35f410 ("Revert "riscv: Add a Zalrsc-only alternative for
synchronization in start.S"") has been merged this night. Hence the
current patch is superseded.
ibex-ast2700_defconfig for which the original patch was developed does
not build w/ or w/o the revert ("undefined reference to `__ashldi3'") on
Ubuntu 25.10 using GCC 15.2.
---
Hi Heinrich,
Thanks for sending the patch!
Hello Yao,
It would be worthwhile to understand why your new method does not work on
the StarFive VisionFive 2. I only addressed the Kconfig issue. But I suspect
there is something broken in the alternative pass.
A possible reason is that, on JH7110 not all the cores support LR/SC
instructions: the S7 small core always raises access exception for it
since the implementation of LR/SC requires data cache to present, while
S7 doesn't have one.
@Hal, @Minda
does the S7 core enter U-Boot SPL at all?
Best regards
Heinrich
This is documented in SiFive U74-MC Core Complex Manual,
Load-reserved (LR) and store-conditional (SC) instructions are special
atomic instructions that are only supported in data cacheable regions.
As the S7 core does not have a data cache, the LR and SC instructions
will always generate a precise access exception.[1]
As S7 also takes part in the initial HART lottery, usage of LR/SC
instructions might just crash its boot process with exception.
However I could only confirm the idea days later when I have access to
a JH7110 board. Since earlier Tom has merged the patch[2] that reverts
the problematic commit, do you think it's better to wait for me to
confirm the cause and write v3 of the patch, instead of fixing it up
now? I'll carry your Co-developed-by tag in v3 if you're okay with this.
Best regards
Heinrich
Best regards,
Yao Zi
[1]: https://starfivetech.com/uploads/u74mc_core_complex_manual_21G1.pdf
(Chapter 3.6, Atomic Memory Operations)
[2]:
https://lore.kernel.org/u-boot/[email protected]/
