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

Tue Feb 28 23:19:55 CET 2023

On Tuesday 28 February 2023 13:51:24 Tony Dinh wrote:
> 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.

Perfect!

> >
> > 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.

Ok, this looks correct. BootROM prints that boots from SPI and SPL just
needs correct bootstrap detection.

I would propose to rather define some macro e.g.
BOOT_FROM_IS_SPI(boot_device)
which returns true if boot_device is any SPI option as defined in HW
spec. And not just two options.

> <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?