Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Stefan, On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > Hi Stefan, > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > > > Hi Tony, > > > > On 2/27/23 01:11, Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > >> > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > >>> Hi Martin, > > >>> > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > > >>> wrote: > > > > >>> I'm not sure how to run proper timing tests on the process, but > > >>> stopwatch timing just between seeing "Trying to boot" and "U-Boot > > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and the > > >>> direct from SPI around 4 seconds. I thought the goal of loading from > > >>> SPI directly was speed, but returning to BootROM is significantly > > >>> faster on this board. > > >> > > >> You should check SPI speed in DTS file and also in the defconfig. > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > set in defconfig to get around that bug: > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > That works and is much faster now. I'll submit it in a V2 for these > > two patches once Pali's mvebu changes are accepted. Only question I > > have is: should the faster speed be applied to all three defconfigs? > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > MMC and SATA configs at the moment. > > >>> > > >>> This is only a workaround to get the SPI probe to work correctly. The > > >>> real fix should be in spi_flash_probe() > > >>> ./common/spl/spl_spi.c > > >>> flash = spi_flash_probe(sf_bus, sf_cs, > > >>> CONFIG_SF_DEFAULT_SPEED, > > >>> CONFIG_SF_DEFAULT_MODE); > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > > >>> > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > >>> some other common place. And when we will have fixed the DTS parsing > > >>> problem, they can be removed. > > >>> > > >>> I'd like to hear from Stefan and Pali if this approach sounds good. > > >>> > > >>> All the best, > > >>> Tony > > >> > > >> Well, the maximal SPI speed depends on the wiring. You can have on the > > >> board some SPI device which does not support high frequency. > > >> > > >> But having some sane defaults in Kconfig for mvebu makes sense. > > > > Agreed. > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig > > > does not specify it. I think the sane default value is 10_000_000 > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency > > > is 10_000_000). While a big improvement, it is not fast enough for > > > many other boards. So we still need to define it in those board > > > defconfigs (before fixing that bug), or use return to BootROM. > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > > currently has no platform- / board- specific configurations. Perhaps > > it can be done in a mach-mvebu Kconfig file instead? > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run > some tests. I sent in the patch that should go into u-boot-marvell/next. Thanks, Tony
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Tue, Feb 28, 2023 at 2:19 PM Pali Rohár 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 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 wrote: > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > > 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. > > > > > > > > > > > > > > > > > > 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
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
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 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 wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > 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. > > > > > > > > > > > > > > > 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. > > BootROM - 1.73 > Booting from SPI flash > > U-Boot SPL
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár 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 wrote: > > > > > > > > Hi Pali, > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > 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. > > > > > > > > > > > > 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. 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
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
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 wrote: > > > > > > Hi Pali, > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > 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 0x05c4)... > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > 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 0x05c4)... > > > > 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. > > > > > > > > > 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. 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... > > > spl_boot_device boot_device = 15 > > > board_boot_order spl_boot_list[0] = 15 > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0x05c4)... > > > BootROM: Image checksum verification PASSED > > > > > > > > > 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?
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Monday 27 February 2023 17:17:31 Tony Dinh wrote: > Hi Pali, > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > > > > > > > Hi Stefan, > > > > > > > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > > > > > > > > > Hi Tony, > > > > > > > > > > On 2/27/23 01:11, Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > > > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > > > > >> > > > > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > > > > >>> Hi Martin, > > > > > >>> > > > > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > > > > > >>> wrote: > > > > > > > > > > >>> I'm not sure how to run proper timing tests on the process, > > > > > >>> but > > > > > >>> stopwatch timing just between seeing "Trying to boot" and > > > > > >>> "U-Boot > > > > > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and > > > > > >>> the > > > > > >>> direct from SPI around 4 seconds. I thought the goal of > > > > > >>> loading from > > > > > >>> SPI directly was speed, but returning to BootROM is > > > > > >>> significantly > > > > > >>> faster on this board. > > > > > >> > > > > > >> You should check SPI speed in DTS file and also in the > > > > > >> defconfig. > > > > > > > > > > > > I think we have probably seen this slowdown before. There is a > > > > > > TODO in > > > > > > the way the DTS nodes are parsed by DM uclass. So this config > > > > > > must be > > > > > > set in defconfig to get around that bug: > > > > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > > > > > > > That works and is much faster now. I'll submit it in a V2 for > > > > > these > > > > > two patches once Pali's mvebu changes are accepted. Only > > > > > question I > > > > > have is: should the faster speed be applied to all three > > > > > defconfigs? > > > > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added > > > > > to the > > > > > MMC and SATA configs at the moment. > > > > > >>> > > > > > >>> This is only a workaround to get the SPI probe to work correctly. > > > > > >>> The > > > > > >>> real fix should be in spi_flash_probe() > > > > > >>> ./common/spl/spl_spi.c > > > > > >>> flash = spi_flash_probe(sf_bus, sf_cs, > > > > > >>> CONFIG_SF_DEFAULT_SPEED, > > > > > >>> CONFIG_SF_DEFAULT_MODE); > > > > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > > > > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > > > > > >>> > > > > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > > > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > > > > >>> some other common place. And when we will have fixed the DTS > > > > > >>> parsing > > > > > >>> problem, they can be removed. > > > > > >>> > > > > > >>> I'd like to hear from Stefan and Pali if this approach sounds > > > > > >>> good. > > > > > >>> > > > > > >>> All the best, > > > > > >>> Tony > > > > > >> > > > > > >> Well, the maximal SPI speed depends on the wiring. You can have on > > > > > >> the > > > > > >> board some SPI device which does not support high frequency. > > > > > >> > > > > > >> But having some sane defaults in Kconfig for mvebu makes sense. > > > > > > > > > > Agreed. > > > > > > > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board > > > > > > defconfig > > > > > > does not specify it. I think the sane default value is 10_000_000 > > > > > > (grepping the Armada* DTS files showing the slowest > > > > > > spi-max-frequency > > > > > > is 10_000_000). While a big improvement, it is not fast enough for > > > > > > many other boards. So we still need to define it in those board > > > > > > defconfigs (before fixing that bug), or use return to BootROM. > > > > > > > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > > > > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > > > > > currently has no platform- / board- specific configurations. Perhaps > > > > > it can be done in a mach-mvebu Kconfig file instead? > > > > > > > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run > > > > some tests. > > > > > > 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. > > > > > > > > > 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
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh wrote: > > Hi Pali, > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > > > > > > > Hi Tony, > > > > > > > > On 2/27/23 01:11, Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > > > >> > > > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > > > >>> Hi Martin, > > > > >>> > > > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > > > > >>> wrote: > > > > > > > > >>> I'm not sure how to run proper timing tests on the process, but > > > > >>> stopwatch timing just between seeing "Trying to boot" and > > > > >>> "U-Boot > > > > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and > > > > >>> the > > > > >>> direct from SPI around 4 seconds. I thought the goal of loading > > > > >>> from > > > > >>> SPI directly was speed, but returning to BootROM is > > > > >>> significantly > > > > >>> faster on this board. > > > > >> > > > > >> You should check SPI speed in DTS file and also in the defconfig. > > > > > > > > > > I think we have probably seen this slowdown before. There is a > > > > > TODO in > > > > > the way the DTS nodes are parsed by DM uclass. So this config > > > > > must be > > > > > set in defconfig to get around that bug: > > > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > > > > > That works and is much faster now. I'll submit it in a V2 for these > > > > two patches once Pali's mvebu changes are accepted. Only question I > > > > have is: should the faster speed be applied to all three > > > > defconfigs? > > > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to > > > > the > > > > MMC and SATA configs at the moment. > > > > >>> > > > > >>> This is only a workaround to get the SPI probe to work correctly. > > > > >>> The > > > > >>> real fix should be in spi_flash_probe() > > > > >>> ./common/spl/spl_spi.c > > > > >>> flash = spi_flash_probe(sf_bus, sf_cs, > > > > >>> CONFIG_SF_DEFAULT_SPEED, > > > > >>> CONFIG_SF_DEFAULT_MODE); > > > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > > > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > > > > >>> > > > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > > > >>> some other common place. And when we will have fixed the DTS parsing > > > > >>> problem, they can be removed. > > > > >>> > > > > >>> I'd like to hear from Stefan and Pali if this approach sounds good. > > > > >>> > > > > >>> All the best, > > > > >>> Tony > > > > >> > > > > >> Well, the maximal SPI speed depends on the wiring. You can have on > > > > >> the > > > > >> board some SPI device which does not support high frequency. > > > > >> > > > > >> But having some sane defaults in Kconfig for mvebu makes sense. > > > > > > > > Agreed. > > > > > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig > > > > > does not specify it. I think the sane default value is 10_000_000 > > > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency > > > > > is 10_000_000). While a big improvement, it is not fast enough for > > > > > many other boards. So we still need to define it in those board > > > > > defconfigs (before fixing that bug), or use return to BootROM. > > > > > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > > > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > > > > currently has no platform- / board- specific configurations. Perhaps > > > > it can be done in a mach-mvebu Kconfig file instead? > > > > > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run > > > some tests. > > > > 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. > > > > > > 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 0x05c4)... > > BootROM: Image checksum verification PASSED > > > > > > 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 > >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh wrote: > > Hi Pali, > > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > > > Hi Stefan, > > > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > > > > > Hi Tony, > > > > > > On 2/27/23 01:11, Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > > >> > > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > > >>> Hi Martin, > > > >>> > > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > > > >>> wrote: > > > > > > >>> I'm not sure how to run proper timing tests on the process, but > > > >>> stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > >>> direct from SPI around 4 seconds. I thought the goal of loading > > > >>> from > > > >>> SPI directly was speed, but returning to BootROM is significantly > > > >>> faster on this board. > > > >> > > > >> You should check SPI speed in DTS file and also in the defconfig. > > > > > > > > I think we have probably seen this slowdown before. There is a TODO > > > > in > > > > the way the DTS nodes are parsed by DM uclass. So this config must > > > > be > > > > set in defconfig to get around that bug: > > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > > > That works and is much faster now. I'll submit it in a V2 for these > > > two patches once Pali's mvebu changes are accepted. Only question I > > > have is: should the faster speed be applied to all three defconfigs? > > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > > MMC and SATA configs at the moment. > > > >>> > > > >>> This is only a workaround to get the SPI probe to work correctly. The > > > >>> real fix should be in spi_flash_probe() > > > >>> ./common/spl/spl_spi.c > > > >>> flash = spi_flash_probe(sf_bus, sf_cs, > > > >>> CONFIG_SF_DEFAULT_SPEED, > > > >>> CONFIG_SF_DEFAULT_MODE); > > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > > > >>> > > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > > >>> some other common place. And when we will have fixed the DTS parsing > > > >>> problem, they can be removed. > > > >>> > > > >>> I'd like to hear from Stefan and Pali if this approach sounds good. > > > >>> > > > >>> All the best, > > > >>> Tony > > > >> > > > >> Well, the maximal SPI speed depends on the wiring. You can have on the > > > >> board some SPI device which does not support high frequency. > > > >> > > > >> But having some sane defaults in Kconfig for mvebu makes sense. > > > > > > Agreed. > > > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig > > > > does not specify it. I think the sane default value is 10_000_000 > > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency > > > > is 10_000_000). While a big improvement, it is not fast enough for > > > > many other boards. So we still need to define it in those board > > > > defconfigs (before fixing that bug), or use return to BootROM. > > > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > > > currently has no platform- / board- specific configurations. Perhaps > > > it can be done in a mach-mvebu Kconfig file instead? > > > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run > > some tests. > > 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. > > > 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 0x05c4)... > BootROM: Image checksum verification PASSED > > > 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 0x05c4)... > BootROM: Image checksum verification PASSED It turns out that the board strapping register itself is the problem. boot_device=0x9 was printed out in
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > Hi Stefan, > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > > > Hi Tony, > > > > On 2/27/23 01:11, Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > >> > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > >>> Hi Martin, > > >>> > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > > >>> wrote: > > > > >>> I'm not sure how to run proper timing tests on the process, but > > >>> stopwatch timing just between seeing "Trying to boot" and "U-Boot > > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and the > > >>> direct from SPI around 4 seconds. I thought the goal of loading from > > >>> SPI directly was speed, but returning to BootROM is significantly > > >>> faster on this board. > > >> > > >> You should check SPI speed in DTS file and also in the defconfig. > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > set in defconfig to get around that bug: > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > That works and is much faster now. I'll submit it in a V2 for these > > two patches once Pali's mvebu changes are accepted. Only question I > > have is: should the faster speed be applied to all three defconfigs? > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > MMC and SATA configs at the moment. > > >>> > > >>> This is only a workaround to get the SPI probe to work correctly. The > > >>> real fix should be in spi_flash_probe() > > >>> ./common/spl/spl_spi.c > > >>> flash = spi_flash_probe(sf_bus, sf_cs, > > >>> CONFIG_SF_DEFAULT_SPEED, > > >>> CONFIG_SF_DEFAULT_MODE); > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > > >>> > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > >>> some other common place. And when we will have fixed the DTS parsing > > >>> problem, they can be removed. > > >>> > > >>> I'd like to hear from Stefan and Pali if this approach sounds good. > > >>> > > >>> All the best, > > >>> Tony > > >> > > >> Well, the maximal SPI speed depends on the wiring. You can have on the > > >> board some SPI device which does not support high frequency. > > >> > > >> But having some sane defaults in Kconfig for mvebu makes sense. > > > > Agreed. > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig > > > does not specify it. I think the sane default value is 10_000_000 > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency > > > is 10_000_000). While a big improvement, it is not fast enough for > > > many other boards. So we still need to define it in those board > > > defconfigs (before fixing that bug), or use return to BootROM. > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > > currently has no platform- / board- specific configurations. Perhaps > > it can be done in a mach-mvebu Kconfig file instead? > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run > some tests. 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. 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 0x05c4)... BootROM: Image checksum verification PASSED 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 0x05c4)... BootROM: Image checksum verification PASSED
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Stefan, On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese wrote: > > Hi Tony, > > On 2/27/23 01:11, Tony Dinh wrote: > > Hi Pali, > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > >> > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > >>> Hi Martin, > >>> > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe > >>> wrote: > > >>> I'm not sure how to run proper timing tests on the process, but > >>> stopwatch timing just between seeing "Trying to boot" and "U-Boot > >>> 2023.04-rc2" showed the return to BootROM under 1 second, and the > >>> direct from SPI around 4 seconds. I thought the goal of loading from > >>> SPI directly was speed, but returning to BootROM is significantly > >>> faster on this board. > >> > >> You should check SPI speed in DTS file and also in the defconfig. > > > > I think we have probably seen this slowdown before. There is a TODO in > > the way the DTS nodes are parsed by DM uclass. So this config must be > > set in defconfig to get around that bug: > > CONFIG_SF_DEFAULT_SPEED=5000 > > That works and is much faster now. I'll submit it in a V2 for these > two patches once Pali's mvebu changes are accepted. Only question I > have is: should the faster speed be applied to all three defconfigs? > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > MMC and SATA configs at the moment. > >>> > >>> This is only a workaround to get the SPI probe to work correctly. The > >>> real fix should be in spi_flash_probe() > >>> ./common/spl/spl_spi.c > >>> flash = spi_flash_probe(sf_bus, sf_cs, > >>> CONFIG_SF_DEFAULT_SPEED, > >>> CONFIG_SF_DEFAULT_MODE); > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the > >>> fallback is CONFIG_SF_DEFAULT_SPEED. > >>> > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > >>> some other common place. And when we will have fixed the DTS parsing > >>> problem, they can be removed. > >>> > >>> I'd like to hear from Stefan and Pali if this approach sounds good. > >>> > >>> All the best, > >>> Tony > >> > >> Well, the maximal SPI speed depends on the wiring. You can have on the > >> board some SPI device which does not support high frequency. > >> > >> But having some sane defaults in Kconfig for mvebu makes sense. > > Agreed. > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig > > does not specify it. I think the sane default value is 10_000_000 > > (grepping the Armada* DTS files showing the slowest spi-max-frequency > > is 10_000_000). While a big improvement, it is not fast enough for > > many other boards. So we still need to define it in those board > > defconfigs (before fixing that bug), or use return to BootROM. > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this > currently has no platform- / board- specific configurations. Perhaps > it can be done in a mach-mvebu Kconfig file instead? Yes, I think it should be done in mach-mvebu Kconfig, too. I will run some tests. Thanks, Tony
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Tony, On 2/27/23 01:11, Tony Dinh wrote: Hi Pali, On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: Hi Martin, On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board. You should check SPI speed in DTS file and also in the defconfig. I think we have probably seen this slowdown before. There is a TODO in the way the DTS nodes are parsed by DM uclass. So this config must be set in defconfig to get around that bug: CONFIG_SF_DEFAULT_SPEED=5000 That works and is much faster now. I'll submit it in a V2 for these two patches once Pali's mvebu changes are accepted. Only question I have is: should the faster speed be applied to all three defconfigs? CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the MMC and SATA configs at the moment. This is only a workaround to get the SPI probe to work correctly. The real fix should be in spi_flash_probe() ./common/spl/spl_spi.c flash = spi_flash_probe(sf_bus, sf_cs, CONFIG_SF_DEFAULT_SPEED, CONFIG_SF_DEFAULT_MODE); If spi_flash_probe() failed to get SPI max_hz from the DTS, the fallback is CONFIG_SF_DEFAULT_SPEED. IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or some other common place. And when we will have fixed the DTS parsing problem, they can be removed. I'd like to hear from Stefan and Pali if this approach sounds good. All the best, Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense. Agreed. The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig does not specify it. I think the sane default value is 10_000_000 (grepping the Armada* DTS files showing the slowest spi-max-frequency is 10_000_000). While a big improvement, it is not fast enough for many other boards. So we still need to define it in those board defconfigs (before fixing that bug), or use return to BootROM. I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. Not sure if this should be done in drivers/mtd/spi/Kconfig, as this currently has no platform- / board- specific configurations. Perhaps it can be done in a mach-mvebu Kconfig file instead? Thanks, Stefan
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > Hi Martin, > > > > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: > > > > > > > > > I'm not sure how to run proper timing tests on the process, but > > > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > > > > SPI directly was speed, but returning to BootROM is significantly > > > > > > faster on this board. > > > > > > > > > > You should check SPI speed in DTS file and also in the defconfig. > > > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > > set in defconfig to get around that bug: > > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > > > That works and is much faster now. I'll submit it in a V2 for these > > > two patches once Pali's mvebu changes are accepted. Only question I > > > have is: should the faster speed be applied to all three defconfigs? > > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > > MMC and SATA configs at the moment. > > > > This is only a workaround to get the SPI probe to work correctly. The > > real fix should be in spi_flash_probe() > > ./common/spl/spl_spi.c > > flash = spi_flash_probe(sf_bus, sf_cs, > > CONFIG_SF_DEFAULT_SPEED, > > CONFIG_SF_DEFAULT_MODE); > > If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > fallback is CONFIG_SF_DEFAULT_SPEED. > > > > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > some other common place. And when we will have fixed the DTS parsing > > problem, they can be removed. > > > > I'd like to hear from Stefan and Pali if this approach sounds good. > > > > All the best, > > Tony > > Well, the maximal SPI speed depends on the wiring. You can have on the > board some SPI device which does not support high frequency. > > But having some sane defaults in Kconfig for mvebu makes sense. The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig does not specify it. I think the sane default value is 10_000_000 (grepping the Armada* DTS files showing the slowest spi-max-frequency is 10_000_000). While a big improvement, it is not fast enough for many other boards. So we still need to define it in those board defconfigs (before fixing that bug), or use return to BootROM. All the best, Tony,
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > Hi Martin, > > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: > > > > > > > I'm not sure how to run proper timing tests on the process, but > > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > > > SPI directly was speed, but returning to BootROM is significantly > > > > > faster on this board. > > > > > > > > You should check SPI speed in DTS file and also in the defconfig. > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > set in defconfig to get around that bug: > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > That works and is much faster now. I'll submit it in a V2 for these > > two patches once Pali's mvebu changes are accepted. Only question I > > have is: should the faster speed be applied to all three defconfigs? > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > MMC and SATA configs at the moment. > > This is only a workaround to get the SPI probe to work correctly. The > real fix should be in spi_flash_probe() > ./common/spl/spl_spi.c > flash = spi_flash_probe(sf_bus, sf_cs, > CONFIG_SF_DEFAULT_SPEED, > CONFIG_SF_DEFAULT_MODE); > If spi_flash_probe() failed to get SPI max_hz from the DTS, the > fallback is CONFIG_SF_DEFAULT_SPEED. > > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > some other common place. And when we will have fixed the DTS parsing > problem, they can be removed. > > I'd like to hear from Stefan and Pali if this approach sounds good. > > All the best, > Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense.
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Martin, On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: > > > > > I'm not sure how to run proper timing tests on the process, but > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > > SPI directly was speed, but returning to BootROM is significantly > > > > faster on this board. > > > > > > You should check SPI speed in DTS file and also in the defconfig. > > > > I think we have probably seen this slowdown before. There is a TODO in > > the way the DTS nodes are parsed by DM uclass. So this config must be > > set in defconfig to get around that bug: > > CONFIG_SF_DEFAULT_SPEED=5000 > > That works and is much faster now. I'll submit it in a V2 for these > two patches once Pali's mvebu changes are accepted. Only question I > have is: should the faster speed be applied to all three defconfigs? > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > MMC and SATA configs at the moment. This is only a workaround to get the SPI probe to work correctly. The real fix should be in spi_flash_probe() ./common/spl/spl_spi.c flash = spi_flash_probe(sf_bus, sf_cs, CONFIG_SF_DEFAULT_SPEED, CONFIG_SF_DEFAULT_MODE); If spi_flash_probe() failed to get SPI max_hz from the DTS, the fallback is CONFIG_SF_DEFAULT_SPEED. IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or some other common place. And when we will have fixed the DTS parsing problem, they can be removed. I'd like to hear from Stefan and Pali if this approach sounds good. All the best, Tony
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
> > > I'm not sure how to run proper timing tests on the process, but > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > SPI directly was speed, but returning to BootROM is significantly > > > faster on this board. > > > > You should check SPI speed in DTS file and also in the defconfig. > > I think we have probably seen this slowdown before. There is a TODO in > the way the DTS nodes are parsed by DM uclass. So this config must be > set in defconfig to get around that bug: > CONFIG_SF_DEFAULT_SPEED=5000 That works and is much faster now. I'll submit it in a V2 for these two patches once Pali's mvebu changes are accepted. Only question I have is: should the faster speed be applied to all three defconfigs? CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the MMC and SATA configs at the moment.
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, Hi Martin, On Sat, Feb 25, 2023 at 5:41 AM Pali Rohár wrote: > > On Saturday 25 February 2023 11:47:07 Martin Rowe wrote: > > > While I haven't tested this patchset - I have tested SPI booting with > > > v2022.01 after applying lots of patches. > > > I found that the magic value reported by bootrom when booting from SPI > > > will be 0x34 on clearfog. > > > The current sources only handle 0x32, hence having or not having SPL_SPI > > > will always lead to returning to the bootrom. > > > > > > Please consider pulling in this patch: > > > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > > > I can send it separately if you like. > > > > Tested with the patch on a Clearfog Base: > > == Without SPL_SPI same return to BootROM > > ... > > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0x05c4)... > > BootROM: Image checksum verification PASSED > > > > > > U-Boot 2023.04-rc2... > > == With SPL_SPI loads directly from SPI > > ... > > mv_ddr: completed successfully > > Trying to boot from SPI > > > > > > U-Boot 2023.04-rc2... > > == > > > > I'm not sure how to run proper timing tests on the process, but > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > direct from SPI around 4 seconds. I thought the goal of loading from > > SPI directly was speed, but returning to BootROM is significantly > > faster on this board. > > You should check SPI speed in DTS file and also in the defconfig. I think we have probably seen this slowdown before. There is a TODO in the way the DTS nodes are parsed by DM uclass. So this config must be set in defconfig to get around that bug: CONFIG_SF_DEFAULT_SPEED=5000 All the best, Tony > > > > which I have tested by adding these config options: > > > > I tested the new spi_defconfig with and without SPL_SPI; no other changes
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:51:28 Josua Mayer wrote: > While I haven't tested this patchset Are you going to test it? > I have tested SPI booting with > v2022.01 after applying lots of patches. > I found that the magic value reported by bootrom when booting from SPI will > be 0x34 on clearfog. > The current sources only handle 0x32, hence having or not having SPL_SPI > will always lead to returning to the bootrom. > > Please consider pulling in this patch: > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > I can send it separately if you like. There are lot of more strapping boot options for SPI and for other peripherals. All are described in the A38x Hardware Specifications document, publicly available and linked from the Linux ARM Marvell documentation. Maybe it would make sense to rework this code to handle all combinations and not just selected one? > which I have tested by adding these config options: > > |CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y # CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC is > not set # CONFIG_SPL_MMC is not set CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y CONFIG_SPL_SPI_FLASH_TINY=y CONFIG_SPL_SPI_LOAD=y > CONFIG_SYS_SPI_U_BOOT_OFFS=0x0 # CONFIG_ENV_IS_IN_MMC is not set > CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_ENV_SECT_SIZE_AUTO is not set # > CONFIG_USE_ENV_SPI_BUS is not set # CONFIG_USE_ENV_SPI_CS is not set # > CONFIG_USE_ENV_SPI_MAX_HZ is not set # CONFIG_USE_ENV_SPI_MODE is not set # > CONFIG_ENV_SPI_EARLY is not set CONFIG_ENV_ADDR=0x0| > > > > > CONFIG_SYS_LOAD_ADDR=0x80 > > > > CONFIG_DEBUG_UART=y > > > > CONFIG_AHCI=y > > > > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y > > > > CONFIG_I2C_EEPROM=y > > > > CONFIG_SPL_I2C_EEPROM=y > > > > CONFIG_MMC_BROKEN_CD=y > > > > +CONFIG_SPL_DM_MMC=y > > > > CONFIG_SUPPORT_EMMC_BOOT=y > > > > CONFIG_MMC_SDHCI=y > > > > CONFIG_MMC_SDHCI_SDMA=y > > > > -- > > > > 2.39.2 > > > >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:47:07 Martin Rowe wrote: > > While I haven't tested this patchset - I have tested SPI booting with > > v2022.01 after applying lots of patches. > > I found that the magic value reported by bootrom when booting from SPI will > > be 0x34 on clearfog. > > The current sources only handle 0x32, hence having or not having SPL_SPI > > will always lead to returning to the bootrom. > > > > Please consider pulling in this patch: > > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > > I can send it separately if you like. > > Tested with the patch on a Clearfog Base: > == Without SPL_SPI same return to BootROM > ... > mv_ddr: completed successfully > Trying to boot from BOOTROM > Returning to BootROM (return address 0x05c4)... > BootROM: Image checksum verification PASSED > > > U-Boot 2023.04-rc2... > == With SPL_SPI loads directly from SPI > ... > mv_ddr: completed successfully > Trying to boot from SPI > > > U-Boot 2023.04-rc2... > == > > I'm not sure how to run proper timing tests on the process, but > stopwatch timing just between seeing "Trying to boot" and "U-Boot > 2023.04-rc2" showed the return to BootROM under 1 second, and the > direct from SPI around 4 seconds. I thought the goal of loading from > SPI directly was speed, but returning to BootROM is significantly > faster on this board. You should check SPI speed in DTS file and also in the defconfig. > > which I have tested by adding these config options: > > I tested the new spi_defconfig with and without SPL_SPI; no other changes
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
> While I haven't tested this patchset - I have tested SPI booting with > v2022.01 after applying lots of patches. > I found that the magic value reported by bootrom when booting from SPI will > be 0x34 on clearfog. > The current sources only handle 0x32, hence having or not having SPL_SPI will > always lead to returning to the bootrom. > > Please consider pulling in this patch: > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > I can send it separately if you like. Tested with the patch on a Clearfog Base: == Without SPL_SPI same return to BootROM ... mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... BootROM: Image checksum verification PASSED U-Boot 2023.04-rc2... == With SPL_SPI loads directly from SPI ... mv_ddr: completed successfully Trying to boot from SPI U-Boot 2023.04-rc2... == I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board. > which I have tested by adding these config options: I tested the new spi_defconfig with and without SPL_SPI; no other changes
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, Martin,
Am 25.02.23 um 10:48 schrieb Martin Rowe:
On Sat, 25 Feb 2023 at 07:41, Pali Rohár wrote:
On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.
Signed-off-by: Martin Rowe
---
.../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 93%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index 84f900bf50..31b1e9fce8 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_GPIO=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
Any reason to disable it?
It's the same as MMC and SATA defconfigs this way, it just needs to be
explicit here because of something SPI related that we've enabled.
SPL_DM_SPI is enabled in all of the configs, so I'm guessing that it
is providing driver support because everything seems to work without
SPL_SPI.
I re-tested with and without the config and it doesn't seem to change
anything. With it enabled the file is 588K instead of 580K without it,
but that's not really an issue with 4M of flash storage available.
While I haven't tested this patchset - I have tested SPI booting with
v2022.01 after applying lots of patches.
I found that the magic value reported by bootrom when booting from SPI
will be 0x34 on clearfog.
The current sources only handle 0x32, hence having or not having SPL_SPI
will always lead to returning to the bootrom.
Please consider pulling in this patch:
https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
I can send it separately if you like.
which I have tested by adding these config options:
|CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y # CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC
is not set # CONFIG_SPL_MMC is not set CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI=y CONFIG_SPL_SPI_FLASH_TINY=y CONFIG_SPL_SPI_LOAD=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x0 # CONFIG_ENV_IS_IN_MMC is not set
CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_ENV_SECT_SIZE_AUTO is not set #
CONFIG_USE_ENV_SPI_BUS is not set # CONFIG_USE_ENV_SPI_CS is not set #
CONFIG_USE_ENV_SPI_MAX_HZ is not set # CONFIG_USE_ENV_SPI_MODE is not
set # CONFIG_ENV_SPI_EARLY is not set CONFIG_ENV_ADDR=0x0|
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
--
2.39.2
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Sat, 25 Feb 2023 at 07:41, Pali Rohár wrote:
>
> On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is copy of existing
> > clearfog_defconfig file and changed to instruct build system to
> > generate final kwbimage for SPI booting and to store the
> > environment in SPI as well.
> >
> > Signed-off-by: Martin Rowe
> > ---
> > .../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> > copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
> >
> > diff --git a/configs/clearfog_sata_defconfig
> > b/configs/clearfog_spi_defconfig
> > similarity index 93%
> > copy from configs/clearfog_sata_defconfig
> > copy to configs/clearfog_spi_defconfig
> > index 84f900bf50..31b1e9fce8 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_spi_defconfig
> > @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
> > CONFIG_SYS_THUMB_BUILD=y
> > CONFIG_ARCH_MVEBU=y
> > CONFIG_TEXT_BASE=0x0080
> > +CONFIG_SPL_GPIO=y
> > CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > CONFIG_NR_DRAM_BANKS=2
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> > CONFIG_TARGET_CLEARFOG=y
> > -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > +CONFIG_ENV_SECT_SIZE=0x1
> > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > CONFIG_SPL_TEXT_BASE=0x4030
> > +CONFIG_SPL_MMC=y
> > CONFIG_SPL_SERIAL=y
> > CONFIG_SPL_STACK=0x4002c000
> > CONFIG_SPL=y
> > CONFIG_DEBUG_UART_BASE=0xf1012000
> > CONFIG_DEBUG_UART_CLOCK=25000
> > +CONFIG_SPL_LIBDISK_SUPPORT=y
> > +# CONFIG_SPL_SPI is not set
>
> Any reason to disable it?
It's the same as MMC and SATA defconfigs this way, it just needs to be
explicit here because of something SPI related that we've enabled.
SPL_DM_SPI is enabled in all of the configs, so I'm guessing that it
is providing driver support because everything seems to work without
SPL_SPI.
I re-tested with and without the config and it doesn't seem to change
anything. With it enabled the file is 588K instead of 580K without it,
but that's not really an issue with 4M of flash storage available.
> > CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_DEBUG_UART=y
> > CONFIG_AHCI=y
> > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> > CONFIG_I2C_EEPROM=y
> > CONFIG_SPL_I2C_EEPROM=y
> > CONFIG_MMC_BROKEN_CD=y
> > +CONFIG_SPL_DM_MMC=y
> > CONFIG_SUPPORT_EMMC_BOOT=y
> > CONFIG_MMC_SDHCI=y
> > CONFIG_MMC_SDHCI_SDMA=y
> > --
> > 2.39.2
> >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> This new clearfog_spi_defconfig file is copy of existing
> clearfog_defconfig file and changed to instruct build system to
> generate final kwbimage for SPI booting and to store the
> environment in SPI as well.
>
> Signed-off-by: Martin Rowe
> ---
> .../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
>
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
> similarity index 93%
> copy from configs/clearfog_sata_defconfig
> copy to configs/clearfog_spi_defconfig
> index 84f900bf50..31b1e9fce8 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_spi_defconfig
> @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_MVEBU=y
> CONFIG_TEXT_BASE=0x0080
> +CONFIG_SPL_GPIO=y
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> CONFIG_NR_DRAM_BANKS=2
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> CONFIG_TARGET_CLEARFOG=y
> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> +CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> CONFIG_SPL_TEXT_BASE=0x4030
> +CONFIG_SPL_MMC=y
> CONFIG_SPL_SERIAL=y
> CONFIG_SPL_STACK=0x4002c000
> CONFIG_SPL=y
> CONFIG_DEBUG_UART_BASE=0xf1012000
> CONFIG_DEBUG_UART_CLOCK=25000
> +CONFIG_SPL_LIBDISK_SUPPORT=y
> +# CONFIG_SPL_SPI is not set
Any reason to disable it?
> CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SPL_I2C_EEPROM=y
> CONFIG_MMC_BROKEN_CD=y
> +CONFIG_SPL_DM_MMC=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_SDMA=y
> --
> 2.39.2
>
[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.
Signed-off-by: Martin Rowe
---
.../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 93%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index 84f900bf50..31b1e9fce8 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_GPIO=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
--
2.39.2
