[PATCH 0/3] arm: Give the LS1021ATSN board some love

[PATCH 0/3] arm: Give the LS1021ATSN board some love

[Michael Walle]

It seems that (QSPI-boot variant of) the LS1021ATSN board has been
broken for some years now. First, the SPI clock was far too fast
which prevented booting from it, then the serial output was broken.
In fact while debugging the issue, I've noticed that over the
releases more and more stuff got broken. SPI flash isn't working in
u-boot proper and the attached ethernet switch doesn't work either.

FYI, this is what I'm getting at the moment:

U-Boot 2026.04-rc4-00011-g9017eb478b9e (Mar 18 2026 - 15:22:22 +0100)

CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
Clock Configuration:
       CPU0(ARMV7):1200 MHz, 
       Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate), 
Reset Configuration Word (RCW):
       00000000: 0608000c 00000000 00000000 00000000
       00000010: 30000000 08007900 40105a00 21046000
       00000020: 00000000 00000000 00000000 10002000
       00000030: 20124800 8804b340 00000000 00000000
Model: NXP LS1021A-TSN Board
DRAM:  1 GiB
Using SERDES1 Protocol: 48 (0x30)
Core:  37 devices, 16 uclasses, devicetree: separate
MMC:   FSL_SDHC: 0
Loading Environment from SPIFlash... fsl_qspi quadspi@1550000: Invalid chip select 0:0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

EEPROM: Invalid ID (ff ff ff ff)
In:    serial@21c0500
Out:   serial@21c0500
Err:   serial@21c0500
SEC0:  RNG instantiated
Net:   
Warning: ethernet@2d90000 (eth2) using random MAC address - 3e:66:27:46:5b:c8
Unexpected {device ID, part number}: 0x1e00030e 0x9a83
sja1105 ethernet-switch@1: Device ID check failed: -19
eth3: swp2, eth4: swp3, eth5: swp4
Warning: ethernet@2d10000 (eth0) using random MAC address - d6:78:3b:aa:94:b6
, eth0: ethernet@2d10000
Warning: ethernet@2d50000 (eth1) using random MAC address - 12:ce:20:97:a2:79
, eth1: ethernet@2d50000, eth2: ethernet@2d90000
Hit any key to stop autoboot: 0


Michael Walle (3):
  arm: dts: ls1021a-tsn: add default serial output
  configs: ls1021atsn: enable serial driver
  armv7: ls102xa: fix SPI flash clock

 arch/arm/dts/ls1021a-tsn.dts                      | 4 ++++
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
 configs/ls1021atsn_qspi_defconfig                 | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.47.3

[PATCH 1/3] arm: dts: ls1021a-tsn: add default serial output

[Michael Walle]

Since switching to DM_SERIAL 'stdout-path' seems to be necessary.

Signed-off-by: Michael Walle <mwalle@kernel.org>
---
 arch/arm/dts/ls1021a-tsn.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/ls1021a-tsn.dts b/arch/arm/dts/ls1021a-tsn.dts
index 68f5543644e..e74d0956194 100644
--- a/arch/arm/dts/ls1021a-tsn.dts
+++ b/arch/arm/dts/ls1021a-tsn.dts
@@ -22,6 +22,10 @@
 		ethernet5 = &swp4;
 		ethernet6 = &swp5;
 	};
+
+	chosen {
+		stdout-path = &uart0;
+	};
 };
 
 &dspi0 {
-- 
2.47.3

[PATCH 2/3] configs: ls1021atsn: enable serial driver

[Michael Walle]

Switching to DM_SERIAL disabled any serial driver. Re-enable it again.

Fixes: 191b10ac70d7 ("PowerPC / Layerscape: Finish migration to DM_SERIAL")
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
 configs/ls1021atsn_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/ls1021atsn_qspi_defconfig b/configs/ls1021atsn_qspi_defconfig
index e36d336d84b..37629d88c48 100644
--- a/configs/ls1021atsn_qspi_defconfig
+++ b/configs/ls1021atsn_qspi_defconfig
@@ -68,6 +68,7 @@ CONFIG_TSEC_ENET=y
 CONFIG_NVME_PCI=y
 CONFIG_PCIE_LAYERSCAPE_RC=y
 CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
-- 
2.47.3

[PATCH 3/3] armv7: ls102xa: fix SPI flash clock

[Michael Walle]

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/1568804284-25162-1-git-send-email-kuldeep.singh@nxp.com/
Fixes: bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
Signed-off-by: Michael Walle <mwalle@kernel.org>

---
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.
---
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index a0c3da7f46d..51ba8733768 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -137,7 +137,7 @@ struct ccsr_gur {
 #define SCFG_ETSECCMCR_GE0_CLK125	0x00000000
 #define SCFG_ETSECCMCR_GE1_CLK125	0x08000000
 #define SCFG_PIXCLKCR_PXCKEN		0x80000000
-#define SCFG_QSPI_CLKSEL		0x50100000
+#define SCFG_QSPI_CLKSEL		0x30100000
 #define SCFG_SNPCNFGCR_SEC_RD_WR	0xc0000000
 #define SCFG_SNPCNFGCR_DCU_RD_WR	0x03000000
 #define SCFG_SNPCNFGCR_SATA_RD_WR	0x00c00000
-- 
2.47.3

Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock

[Vladimir Oltean]

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/1568804284-25162-1-git-send-email-kuldeep.singh@nxp.com/
> Fixes: bb6f3c0f7634 ("armv7: ls102xa: Update SCFG_QSPI_CLKSEL value")
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> 
> ---
> 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 <olteanv@gmail.com>

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 0x00000803 is
0xC0100000, 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 0xFFFF_FFFF 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.

Re: [PATCH 2/3] configs: ls1021atsn: enable serial driver

[Vladimir Oltean]

On Wed, Mar 18, 2026 at 03:29:16PM +0100, Michael Walle wrote:
> Switching to DM_SERIAL disabled any serial driver. Re-enable it again.
> 
> Fixes: 191b10ac70d7 ("PowerPC / Layerscape: Finish migration to DM_SERIAL")
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
>  configs/ls1021atsn_qspi_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/ls1021atsn_qspi_defconfig b/configs/ls1021atsn_qspi_defconfig
> index e36d336d84b..37629d88c48 100644
> --- a/configs/ls1021atsn_qspi_defconfig
> +++ b/configs/ls1021atsn_qspi_defconfig
> @@ -68,6 +68,7 @@ CONFIG_TSEC_ENET=y
>  CONFIG_NVME_PCI=y
>  CONFIG_PCIE_LAYERSCAPE_RC=y
>  CONFIG_DM_SERIAL=y
> +CONFIG_SYS_NS16550=y
>  CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_FSL_DSPI=y
> -- 
> 2.47.3
> 

Ok, in ls1021atsn_sdcard_defconfig it is selected by
CONFIG_SPL_SYS_NS16550_SERIAL=y. In ls1021atsn_qspi_defconfig it isn't
selected.

Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock

[Michael Walle]

Hi,

On Thu Mar 19, 2026 at 3:11 PM CET, Vladimir Oltean wrote:
> Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

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 0x00000803 is
> 0xC0100000, 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 0xFFFF_FFFF 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 2/3] configs: ls1021atsn: enable serial driver

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Thu, Mar 19, 2026 at 04:19:19PM +0200, Vladimir Oltean wrote:
> On Wed, Mar 18, 2026 at 03:29:16PM +0100, Michael Walle wrote:
> > Switching to DM_SERIAL disabled any serial driver. Re-enable it again.
> > 
> > Fixes: 191b10ac70d7 ("PowerPC / Layerscape: Finish migration to DM_SERIAL")
> > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > ---
> >  configs/ls1021atsn_qspi_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/configs/ls1021atsn_qspi_defconfig b/configs/ls1021atsn_qspi_defconfig
> > index e36d336d84b..37629d88c48 100644
> > --- a/configs/ls1021atsn_qspi_defconfig
> > +++ b/configs/ls1021atsn_qspi_defconfig
> > @@ -68,6 +68,7 @@ CONFIG_TSEC_ENET=y
> >  CONFIG_NVME_PCI=y
> >  CONFIG_PCIE_LAYERSCAPE_RC=y
> >  CONFIG_DM_SERIAL=y
> > +CONFIG_SYS_NS16550=y
> >  CONFIG_SPI=y
> >  CONFIG_DM_SPI=y
> >  CONFIG_FSL_DSPI=y
> > -- 
> > 2.47.3
> > 
> 
> Ok, in ls1021atsn_sdcard_defconfig it is selected by
> CONFIG_SPL_SYS_NS16550_SERIAL=y. In ls1021atsn_qspi_defconfig it isn't
> selected.
> 
> Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

And the ls1021atsn_qspi_defconfig example isn't great, ugh. There's
certainly other platforms I didn't migrate correctly in that commit,
I'll go take a look now.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 2/3] configs: ls1021atsn: enable serial driver

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Thu, Mar 19, 2026 at 08:25:05AM -0600, Tom Rini wrote:
> On Thu, Mar 19, 2026 at 04:19:19PM +0200, Vladimir Oltean wrote:
> > On Wed, Mar 18, 2026 at 03:29:16PM +0100, Michael Walle wrote:
> > > Switching to DM_SERIAL disabled any serial driver. Re-enable it again.
> > > 
> > > Fixes: 191b10ac70d7 ("PowerPC / Layerscape: Finish migration to DM_SERIAL")
> > > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > > ---
> > >  configs/ls1021atsn_qspi_defconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/configs/ls1021atsn_qspi_defconfig b/configs/ls1021atsn_qspi_defconfig
> > > index e36d336d84b..37629d88c48 100644
> > > --- a/configs/ls1021atsn_qspi_defconfig
> > > +++ b/configs/ls1021atsn_qspi_defconfig
> > > @@ -68,6 +68,7 @@ CONFIG_TSEC_ENET=y
> > >  CONFIG_NVME_PCI=y
> > >  CONFIG_PCIE_LAYERSCAPE_RC=y
> > >  CONFIG_DM_SERIAL=y
> > > +CONFIG_SYS_NS16550=y
> > >  CONFIG_SPI=y
> > >  CONFIG_DM_SPI=y
> > >  CONFIG_FSL_DSPI=y
> > > -- 
> > > 2.47.3
> > > 
> > 
> > Ok, in ls1021atsn_sdcard_defconfig it is selected by
> > CONFIG_SPL_SYS_NS16550_SERIAL=y. In ls1021atsn_qspi_defconfig it isn't
> > selected.
> > 
> > Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> 
> And the ls1021atsn_qspi_defconfig example isn't great, ugh. There's
> certainly other platforms I didn't migrate correctly in that commit,
> I'll go take a look now.

It's 39 platforms and I'm running a patch through CI now to make sure
everything builds still with them enabled.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/3] arm: Give the LS1021ATSN board some love

[Peng Fan]

On Wed, Mar 18, 2026 at 03:29:14PM +0100, Michael Walle wrote:
>It seems that (QSPI-boot variant of) the LS1021ATSN board has been
>broken for some years now. First, the SPI clock was far too fast
>which prevented booting from it, then the serial output was broken.
>In fact while debugging the issue, I've noticed that over the
>releases more and more stuff got broken. SPI flash isn't working in
>u-boot proper and the attached ethernet switch doesn't work either.
>
>
>Michael Walle (3):
>  arm: dts: ls1021a-tsn: add default serial output
>  configs: ls1021atsn: enable serial driver
>  armv7: ls102xa: fix SPI flash clock
>

Applied.

Thanks,
Peng

Re: [PATCH 3/3] armv7: ls102xa: fix SPI flash clock

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

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, 0x00000803
+write 0x57015c, 0x0000080c

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]