Hi Pali, On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár <p...@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 <mibo...@gmail.com> wrote: > > > > > > > > Hi Pali, > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibo...@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@70000 (eth0) using random MAC address - 16:55:96:55:52:5e eth0: ethernet@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?