[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

Tue Feb 28 22:51:24 CET 2023

Hi Pali,

On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár <pali at kernel.org> wrote:
>
> On Tuesday 28 February 2023 10:48:24 Pali Rohár wrote:
> > On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi at gmail.com> wrote:
> > > >
> > > > Hi Pali,
> > > >
> > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi at gmail.com> wrote:
> > > > >
> > > > > Hi Pali,
> > > > > It is not related to this patch series (I also tested without the
> > > > > patch series to confirm). But it is strange that I can no longer get
> > > > > the configuration to boot from SPI. The 1st device in the boot order
> > > > > is alway BOOTROM. The spl_boot_list is printed out below.
> > > > >
> > > > > <BEGIN LOG>
> > > > > High speed PHY - Ended Successfully
> > > > > mv_ddr: 14.0.0
> > > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > > mv_ddr: completed successfully
> > > > > board_boot_order spl_boot_list[0] = 15
> > > > > Trying to boot from BOOTROM
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > BootROM: Image checksum verification PASSED
> > > > > <END LOG>
> > > > >
> > > > > The SPL SPI configs (board Thecus N2350) are:
> > > > > # grep SPL .config| grep SPI
> > > > >
> > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > > > CONFIG_SPL_DM_SPI=y
> > > > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > > > CONFIG_SPL_SPI=y
> > > > > CONFIG_SPL_DM_SPI_FLASH=y
> > > > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > > > CONFIG_SPL_SPI_LOAD=y
> > > > >
> > > > > Did I miss something new lately?
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > > >
> > > > > Trying to boot from BOOTROM
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > BootROM: Image checksum verification PASSED
> > > >
> > > > It turns out that the board strapping register itself is the problem.
> > > > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > > > surely does not match what we expected for A38x  (#define
> > > > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > > > it fell to the default case, which is BOOTROM.
> > > >
> > > > <BEGIN LOG>
> > > > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > > > 16:24:01 -0800)
> > > > High speed PHY - Version: 2.0
> > > > Detected Device ID 6820
> > > > board SerDes lanes topology details:
> > > >  | Lane # | Speed |  Type       |
> > > >  --------------------------------
> > > >  |   0    |   0   | SGMII0 |
> > > >  |   1    |   3   | SATA0 |
> > > >  |   2    |   3   | SATA1 |
> > > >  |   4    |   5   | USB3 HOST0 |
> > > >  |   5    |   5   | USB3 HOST1 |
> > > >  --------------------------------
> > > > High speed PHY - Ended Successfully
> > > > mv_ddr: 14.0.0
> > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > mv_ddr: completed successfully
> > > > BOOTROM_REG=0x97001000 boot_device=0x9
>
> Wait...
>
> Stop here. BOOTROM_REG is the value of BOOTROM_ERR_REG register which is
> mvebu register 0x182d0.
>
> Boot strapping pins are available in the SAR_REG register which is mvebu
> register 0x18600 and SPL prints it under name SAR_REG.

Ah, I see. Thanks Pali. I've jumped the gun too soon after seeing the
1st boot_device debug statement! Please see below.

>
> So above boot_device=9 is not strapping pin configuration but something
> parsed from BOOTROM_ERR_REG.
>
> So above 0x9 signal some A385 bootrom error and SPL in case case of any
> error (value different from zero) always use bootrom for loading proper
> u-boot. As it thinks that bootrom loaded u-boot via uart. Seems that
> this assumption is incorrect.
>
> Unfortunately upper four bits which above code parses from mvebu
> register 0x182d0 are marked as reserved in functional specification.
>
> So it is needed to inspect bootrom binary when it sets these bits...

I think I understand the problem now. The strapping is for Spi 1,
which is 0x34, but it has not been defined in u-boot yet. We have only
Spi 0 defined in the code, which is 0x32.

A38x Hardware Specs
0x34
BootROM Enabled, Boot from SPI: Controller #1, 24 address bits, NOR
Flash type, using MPP multiplexing option of SPI on MPP[59:56]

/arch/arm/mach-mvebu/include/mach/soc.h
#define BOOT_FROM_SPI 0x32

Here is the boot log. This time I have the SAR_REG printed out.

<BEGIN LOG>
BootROM - 1.73
Booting from SPI flash

U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
13:13:39 -0800)
High speed PHY - Version: 2.0
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |
 --------------------------------
 |   0    |   0   | SGMII0 |
 |   1    |   3   | SATA0 |
 |   2    |   3   | SATA1 |
 |   4    |   5   | USB3 HOST0 |
 |   5    |   5   | USB3 HOST1 |
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR4 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
BOOTROM_REG=0x97001000 boot_device=0x9
get_boot_device boot_device 0
SAR_REG=0xcb00934c boot_device=0x34
spl_boot_device boot_device = 15
board_boot_order spl_boot_list[0] = 15
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED

U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 13:13:39 -0800)
Thecus N2350

SoC:   MV88F6820-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 32-bit, ECC not enabled)
Core:  62 devices, 22 uclasses, devicetree: separate
MMC:
Loading Environment from SPIFlash... SF: Detected mx25l3205d with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

Model: Thecus N2350
Net:
Warning: ethernet at 70000 (eth0) using random MAC address - 16:55:96:55:52:5e
eth0: ethernet at 70000
Hit any key to stop autoboot:  0
<END LOG>

I guess we can add this to /arch/arm/mach-mvebu/include/mach/soc.h and
make sure the case is added to the switch statement in
arch/arm/mach-mvebu/cpu.c. Let me try this test.

Thanks,
Tony

> > > > spl_boot_device boot_device = 15
> > > > board_boot_order spl_boot_list[0] = 15
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > > BootROM: Image checksum verification PASSED
> > > > <END LOG>
> > > >
> > > > Is there a chance this value 0x9 means something that we have not come across?
> > >
> > > Found the answer in the A38x Hardware Specs. I've never noticed this
> > > before. This board has the Sample at Reset set to boot from NAND!
> > >
> > > "Table 48: Boot Device Mode Options
> > > 0x9
> > > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> > > 4 Address cycles support per page, using MPP multiplexing option of
> > > NAND 8 bits
> > > 0x32
> > > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> > > Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> > >
> > > So what we actually see here is the fall back to BootROM. And BootROM
> > > still loads the image from SPI, ignoring that strapping. Am I confused
> > > or correct? :)
> > >
> > > Thanks,
> > > Tony
> >
> > I already wrote in some thread that in Hardware Specifications are
> > documented all strapping pins options and u-boot has defined just few of
> > them in header files. Beware that strapping pins are SoC specific and so
> > you always need to look at the correct document.
> >
> > About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
> > from bootrom to main u-boot and type of the SoC?