Re: [PATCH 1/1] riscv: consider CONFIG_RISCV_ISA_ZAAMO in SPL too

[Yao Zi <ziyao@disroot.org>]

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 <emil.renner.berthing@canonical.com>
> > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > ---

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.

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/176063629917.212270.1145034876136991424.b4-ty@konsulko.com/