Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock
Hi Vladimir, >> I can take additional RCW patches if you're willing to send them. > > As said above, we have our own repo that isn't a fork of NXPs. If it helps, this is our change: /* QSPI flash clock */ -write 0x57015c, 0x0803 +write 0x57015c, 0x080c -michael signature.asc Description: PGP signature
Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock
Hi,
On Thu Mar 19, 2026 at 3:11 PM CET, Vladimir Oltean wrote:
> Reviewed-by: Vladimir Oltean
Thanks!
> I think we have a problem in the RCW as well.
> https://github.com/nxp-qoriq/rcw/blob/devel/ls1021atsn/SSR_PNS_30/rcw_1200_qspiboot.rcw#L8
> Those values should be interpreted as bit reversed (so 0x0803 is
> 0xC010, i.e. the same value as U-Boot used to write prior to commit
> bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")).
>
> They are reversed because we write to SCFG_QSPI_CFG prior to writing to
> SCFG_SCFGREVCR. In fact the documentation says about the SCFG bit
> reverse register "This register must be written 0x_ as a part of
> initialization sequence before writing to any other SCFG register."
>
> So it seems the QSPI clock frequency might be already out of range
> before U-Boot brings it in range with your patch still.
Yes, I've noticed that too. But we have our own repo of the RCWs for
our boards. But yeah, we've basically copied NXPs values. So the
60MHz speed is still lurking there. But instead of the 75MHz, 60MHz
seems to at least work (and nobody noticed).
> I can take additional RCW patches if you're willing to send them.
As said above, we have our own repo that isn't a fork of NXPs.
> Plus, I see since commit ba89878d7029 ("armv7: ls102xa: make QSPI clock
> selection optional during SoC init") that SYS_FSL_QSPI_SKIP_CLKSEL is an
> option too, maybe that's of interest.
I've seen that, but haven't looked further why there is that option.
Probably, to keep any custom clksel value ;)
-michael
Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock
On Wed, Mar 18, 2026 at 03:29:17PM +0100, Michael Walle wrote:
> Commit bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
> broke the SPI boot on the LS1021ATSN board (ls1021atsn_qspi_defconfig)
> at least.
>
> The commit message reads
>Update SCFG_QSPI_CLKSEL value : 0xC -> 0x5
>which means ClusterPLL/16
>
> The original submitted patch had the following description:
>Value 0xC is reserved. Replace it with correct value 0x5 which
>is ClusterPLL/16
>
> Unfortunatly, the little information which was there, was stripped even
> further. Why is 0x5 the "correct" value? In fact, it seems that the
> upper bit is just ignored and thus the value 0xC translates to 0x4 which
> is ClusterPLL/20. This, will result in a SPI clock of 60MHz (if the PLL
> is clocked at 1.2GHz). But even that is too much for the (default) 03h
> read opcode (max 50MHz). Set the value to ClusterPLL/24 which is 50MHz.
>
> Link:
> https://lore.kernel.org/r/[email protected]/
> Fixes: bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
> Signed-off-by: Michael Walle
>
> ---
> If someone still wants to have a faster clock frequency, because they
> are using the fast read opcode or so, I'd suggest to actually implement
> the .set_speed op in the driver.
> ---
Reviewed-by: Vladimir Oltean
I think we have a problem in the RCW as well.
https://github.com/nxp-qoriq/rcw/blob/devel/ls1021atsn/SSR_PNS_30/rcw_1200_qspiboot.rcw#L8
Those values should be interpreted as bit reversed (so 0x0803 is
0xC010, i.e. the same value as U-Boot used to write prior to commit
bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")).
They are reversed because we write to SCFG_QSPI_CFG prior to writing to
SCFG_SCFGREVCR. In fact the documentation says about the SCFG bit
reverse register "This register must be written 0x_ as a part of
initialization sequence before writing to any other SCFG register."
So it seems the QSPI clock frequency might be already out of range
before U-Boot brings it in range with your patch still.
I can take additional RCW patches if you're willing to send them.
Plus, I see since commit ba89878d7029 ("armv7: ls102xa: make QSPI clock
selection optional during SoC init") that SYS_FSL_QSPI_SKIP_CLKSEL is an
option too, maybe that's of interest.
