Hi Pali, On Tue, Feb 28, 2023 at 2:19 PM Pali Rohár <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <[email protected]> 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@70000 (eth0) using random MAC address - a2:7d:47:5b:4a:dc eth0: ethernet@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@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?
