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