[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Tony Dinh
mibodhi at gmail.com
Wed Mar 1 02:32:53 CET 2023
Hi Pali,
On Tue, Feb 28, 2023 at 2:19 PM Pali Rohár <pali at kernel.org> wrote:
>
> 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.
>
So it works by just adding the bootstrap detection BOOT_FROM_SPI _1
(0x34) to the switch statement. Please see the log below.
<BEGIN LOG>
BootROM - 1.73
Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
16:18:28 -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 = 8
board_boot_order spl_boot_list[0] = 8
Trying to boot from SPI
spl_spi_load_image sf_bus = 0 sf_cs = 0
spi_flash_probe spi_flash
U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 16:18:28 -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 - a2:7d:47:5b:4a:dc
eth0: ethernet at 70000
Hit any key to stop autoboot: 0
N2350 > sf probe 0:0
SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB
N2350 >
<END LOG>
I think the SPI uclass logic is a bit misleading. The SPI device is
assigned bus 0 chip 0, it just means that it is the 1st bus it
detected the SPI flash on. It has no relation to SPI controller 0 or
1.
> 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.
Not sure how to handle this cleanly yet! BOOT_FROM_SPI is defined in
the #ifdef for each SoC (Armada 38x, Armada XP,...) and then used as a
case in the switch statement (for NAND, SPI, SATA....).
Thanks,
Tony
>
> > <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?
More information about the U-Boot
mailing list