Hi Pali,
On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár pali@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@gmail.com wrote:
Hi Pali,
On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh mibodhi@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?