Hi Christopher, On 2024-03-02 22:15, Jonas Karlman wrote: > Hi Christopher, > > On 2024-03-02 17:12, Christopher Obbard wrote: >> Hi Jonas, >> >> On Sat, 2024-03-02 at 16:28 +0100, Jonas Karlman wrote: >>> Hi Christopher, >>> >>> On 2024-03-02 15:34, Christopher Obbard wrote: >>>> Some variants of the ROCK Pi 4 series contain an SPI flash chip, which can >>>> be booted from. This patch enables support in U-Boot for building the >>>> image for the SPI flash, support for booting U-Boot from the SPI flash >>>> chip and support in U-Boot for accessing the SPI flash using `sf` >>>> commands. >>>> >>>> Not all variants (e.g. ROCK Pi 4B, ROCK 4 Model C Plus, ROCK 4SE) come >>>> populated with an SPI flash chip, but have the footprint on the board so >>>> a user could solder their own to the board. With this patchset applied, >>>> these board variants without an SPI flash chip still boot from MMC. >>>> >>>> I have enabled support for both Winbond and XTX SPI flash devices since >>>> different hardware variants have different devices populated: >>>> >>>> - `rockpi4_v13_sch_20181112.pdf` contains a Winbond part `W25Q64FWZPIG` >>>> - `rockpi4_v14_sch_20210114.pdf` contains an XTX part `XT25F32BWOIGT` >>>> >>>> The ROCK Pi 4 I have is marked as "ROCK PI 4 v1.48" and contains an SPI >>>> flash chip from XTX: >>>> >>>> => sf probe >>>> SF: Detected xt25f32 with page size 256 Bytes, erase size 4 KiB, total >>>> 4 MiB >>>> >>>> In the interest of supporting all board variants and not regressing >>>> existing users who boot from MMC, I have enabled support for booting from >>>> both SPI flash chip variants in the defconfig and left the environment >>>> storage location as MMC to not break existing users who have the >>>> environment stored on MMC. >>>> >>>> I have also enabled GigaDevice SPI flash chip support, since without it >>>> U-Boot (unexplainably) fails to load with an error: >>>> >>>> U-Boot SPL 2024.04-rc3-00002-g06b486900e2 (Mar 02 2024 - 13:20:45 >>>> +0000) >>>> Trying to boot from SPI >>>> load_simple_fit: Skip load 'atf-5': image size is 0! >>>> initcall failed at call 000000000029beec (err=-11: Try again) >>>> ### ERROR ### Please RESET the board ### >>> >>> This is possibly because of pinctrl no being configured in SPL. I have a >>> big incoming rk3399 series that tries to fix this for most rk3399 boards. >>> It will be a variant of what I did in [1] for rk3328. >> >> Sounds good! Let me know if you want to take these patches in that series, or >> how you wish to work together to not duplicate work. I am open to suggestions >> if it makes things easier for Kever to merge ;-). >> > > Yeah, there is currently a small mountain of patches targeted rockchip > and some even have tricky depends and some will no longer apply clean. > > I can probably take your patches as part of such bigger series to try > and make it easier for Kever :-). Will try to get something ready for > list by tomorrow.
I have not been able to finish breaking the series up into smaller patches but current work-in-progress changes can be found here: https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-pinctrl-defconfig-v0 I also have a few other patches in the works, related to rk3308, rk3328 and rk35xx: https://github.com/Kwiboo/u-boot-rockchip/commits/rk3xxx-misc-wip Hopefully everything will hit the list throughout the week :-) Please verify that your issues reported in the commit message gets fixed by any of the above three linked branches. > > For now I have pushed your patches on top of current pending rockchip > patches at: > https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-rock-pi-4-spi > > Also added a small fixup patch with my suggested changes, and got it to > boot from SPI on my Rock Pi 4 v1.5. > > However, it looks like there was an issue with resolving spl-boot-device > without the spi flash node being added to spl-boot-order prop. > > U-Boot SPL 2024.04-rc3 (Mar 02 2024 - 19:49:44 +0000) > board_spl_was_booted_from: brom_bootdevice_id 3 maps to > '/spi@ff1d0000/flash@0' > Trying to boot from SPI > rockchip_rk3288_spi spi@ff1d0000: spi_find_chip_select: plat=3ef8a80, cs=0 > jedec_spi_nor flash@0: from 0x000e0000, len d > jedec_spi_nor flash@0: from 0x000e0000, len d > ## Checking hash(es) for config config-1 ... OK > jedec_spi_nor flash@0: from 0x001d2600, len d > ## Checking hash(es) for Image atf-1 ... sha256+ OK > jedec_spi_nor flash@0: from 0x000e0a00, len d > ## Checking hash(es) for Image u-boot ... sha256+ OK > jedec_spi_nor flash@0: from 0x0020ea00, len d > ## Checking hash(es) for Image fdt-1 ... sha256+ OK > jedec_spi_nor flash@0: from 0x00205a00, len d > ## Checking hash(es) for Image atf-2 ... sha256+ OK > jedec_spi_nor flash@0: from 0x00207a00, len d > ## Checking hash(es) for Image atf-3 ... sha256+ OK > board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0 > spl_decode_boot_device: could not find udevice for /mmc@fe330000 > spl_decode_boot_device: could not find udevice for /mmc@fe320000 > spl_perform_fixups: could not map boot_device to ofpath: -19 > > There is an issue with board_spl_was_booted_from() not using same boot > source id when spl_perform_fixups() is run. Before loading images id is > 3 and after loading atf images it the boot id is 0. > > Looks like both open source and rockchip TF-A wants to load data to > 0xff8c0000 so SPL happily overwrites the BROM_BOOTSOURCE_ID_ADDR. > > Maybe we need to save the bootsource id for later use to make > spl_perform_fixups() work correctly when booting from SPI. > > Guess we do need to keep the flash node in spl-boot-order until > spl_perform_fixups() is fixed. Using a static variable on bss worked like a charm and I pushed a WIP patch on the branch mentioned above. Regards, Jonas > >> >>> >>> BROM will only configure pinctrl for each device it tries to locate IDB >>> from, so if it locates IDB in SPL it will not have configured emmc or >>> sd-card. So for SPL to be able to fall back on other storage it will >>> need to do proper pinctrl. >>> >>> [1] https://patchwork.ozlabs.org/cover/1900345/ >>> >>>> >>>> Building with `CONFIG_SPL_FIT_SIGNATURE=y` causes an error when booting >>>> from SPI flash, so I disabled it: >>>> >>>> U-Boot 2024.04-rc3-00010-g2e7974a13b9 (Mar 02 2024 - 14:00:17 +0000) >>>> SoC: Rockchip rk3399 >>>> Reset cause: unknown reset >>>> Model: Radxa ROCK Pi 4A >>>> DRAM: initcall failed at call 0000000000228efc (err=-19: No such >>>> device) >>>> ### ERROR ### Please RESET the board ### >>> >>> This is unexpected but if your u-boot.bin is close to or larger then 1 >>> MiB the stack and pre-alloc heap may be overlapping with U-Boot proper >>> or the FDT. That can cause all sort of strange and unexpected issues :-) >>> >>> Have another incoming series to address this for RK3328, RK3399 and >>> ROCK 5A [2]. Should hit list later today, it will be a rework of [3]. >> >> Great, please keep me in CC of those series and I will test & rebase my work >> on top. > > Patches to allow for u-boot.bin bigger than around 1000+ KiB on RK3399 > have now been posted. > > Please verify if that series solved the unexplainable behavior you > described in commit message, and if it makes fit signature check work > again. > > Regards, > Jonas > >> >> >> Thanks! >> Chris >> >>> >>> [2] >>> https://github.com/Kwiboo/u-boot-rockchip/compare/2011cf069a8b...9767374d6a8a >>> [3] https://patchwork.ozlabs.org/cover/1900376/ >>> >>>> >>>> Signed-off-by: Christopher Obbard <chris.obb...@collabora.com> >>>> --- >>>> >>>> arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi | 12 ++++++++++++ >>>> configs/rock-pi-4-rk3399_defconfig | 15 +++++++++++++-- >>>> 2 files changed, 25 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi >>>> b/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi >>>> index 85ee5770add..04c152a291f 100644 >>>> --- a/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi >>>> +++ b/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi >>>> @@ -4,3 +4,15 @@ >>>> */ >>>> >>>> #include "rk3399-rock-pi-4-u-boot.dtsi" >>>> + >>>> +/ { >>>> + chosen { >>>> + u-boot,spl-boot-order = "same-as-spl", &spi_flash, >>>> &sdhci, &sdmmc; >>> >>> I would not recommend adding spi_flash here, especially if you have >>> SPL_FIT_SIGNATURE disabled, and even more so if someone accidentally >>> enable SPL_RAW_IMAGE_SUPPORT. >>> >>> Ideally, we only load TPL/SPL+FIT from same storage, as provided by >>> same-as-spl, however, if we cannot load from the same storage that >>> TPL/SPL was loaded from, for recovery purposes it is typically easier to >>> fall back on sd-card followed by emmc. >>> >>> Normally I would expect that if board does not boot TPL/SPL from SPI, >>> there is no real reason to try and load FIT from SPI. >>> >>> If the FIT cannot be loaded from SPI with same-as-spl alone there is >>> possible some other issue that we need to resolve. >>> >>>> + }; >>>> +}; >>>> + >>>> +&spi1 { >>>> + spi_flash: flash@0 { >>>> + bootph-all; >>>> + }; >>>> +}; >>>> diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4- >>>> rk3399_defconfig >>>> index 83fc4ad7dab..3a38b51c46b 100644 >>>> --- a/configs/rock-pi-4-rk3399_defconfig >>>> +++ b/configs/rock-pi-4-rk3399_defconfig >>>> @@ -6,25 +6,28 @@ CONFIG_TEXT_BASE=0x00200000 >>>> CONFIG_NR_DRAM_BANKS=1 >>>> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y >>>> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 >>>> +CONFIG_SF_DEFAULT_SPEED=10000000 >>>> CONFIG_ENV_OFFSET=0x3F8000 >>>> CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-pi-4a" >>>> CONFIG_OF_LIBFDT_OVERLAY=y >>>> CONFIG_DM_RESET=y >>>> CONFIG_ROCKCHIP_RK3399=y >>>> +CONFIG_ROCKCHIP_SPI_IMAGE=y >>>> CONFIG_TARGET_EVB_RK3399=y >>>> CONFIG_SPL_STACK=0x400000 >>>> CONFIG_DEBUG_UART_BASE=0xFF1A0000 >>>> CONFIG_DEBUG_UART_CLOCK=24000000 >>>> +CONFIG_SPL_SPI_FLASH_SUPPORT=y >>>> +CONFIG_SPL_SPI=y >>>> CONFIG_SYS_LOAD_ADDR=0x800800 >>>> CONFIG_PCI=y >>>> CONFIG_DEBUG_UART=y >>>> # CONFIG_ANDROID_BOOT_IMAGE is not set >>>> -CONFIG_SPL_FIT_SIGNATURE=y >>>> CONFIG_LEGACY_IMAGE_FORMAT=y >>>> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4a.dtb" >>>> CONFIG_DISPLAY_BOARDINFO_LATE=y >>>> CONFIG_MISC_INIT_R=y >>>> -CONFIG_SPL_MAX_SIZE=0x2e000 >>>> +CONFIG_SPL_MAX_SIZE=0x40000 >>>> CONFIG_SPL_PAD_TO=0x7f8000 >>>> CONFIG_SPL_HAS_BSS_LINKER_SECTION=y >>>> CONFIG_SPL_BSS_START_ADDR=0x400000 >>>> @@ -33,6 +36,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 >>>> # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set >>>> CONFIG_SPL_STACK_R=y >>>> CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 >>>> +CONFIG_SPL_SPI_LOAD=y >>>> +CONFIG_SYS_SPI_U_BOOT_OFFS=0xE0000 >>>> CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y >>>> CONFIG_TPL=y >>>> CONFIG_CMD_BOOTZ=y >>>> @@ -52,6 +57,7 @@ CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names >>>> clock-names interrupt-parent >>>> CONFIG_ENV_IS_IN_MMC=y >>>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >>>> CONFIG_DFU_MMC=y >>>> +CONFIG_SPL_DM_SEQ_ALIAS=y >>>> CONFIG_ROCKCHIP_GPIO=y >>>> CONFIG_SYS_I2C_ROCKCHIP=y >>>> CONFIG_MISC=y >>>> @@ -61,6 +67,10 @@ CONFIG_MMC_DW_ROCKCHIP=y >>>> CONFIG_MMC_SDHCI=y >>>> CONFIG_MMC_SDHCI_SDMA=y >>>> CONFIG_MMC_SDHCI_ROCKCHIP=y >>>> +CONFIG_SF_DEFAULT_BUS=1 >>> >>> Would recommend adding following to allow reading SFDP properties from >>> flash, it is what I am doing to all other rk boards with spi flash: >>> >>> CONFIG_SPI_FLASH_SFDP_SUPPORT=y >>> >>> Regards, >>> Jonas >>> >>>> +CONFIG_SPI_FLASH_GIGADEVICE=y >>>> +CONFIG_SPI_FLASH_WINBOND=y >>>> +CONFIG_SPI_FLASH_XTX=y >>>> CONFIG_ETH_DESIGNWARE=y >>>> CONFIG_GMAC_ROCKCHIP=y >>>> CONFIG_NVME_PCI=y >>>> @@ -74,6 +84,7 @@ CONFIG_RAM_ROCKCHIP_LPDDR4=y >>>> CONFIG_BAUDRATE=1500000 >>>> CONFIG_DEBUG_UART_SHIFT=2 >>>> CONFIG_SYS_NS16550_MEM32=y >>>> +CONFIG_ROCKCHIP_SPI=y >>>> CONFIG_SYSRESET=y >>>> CONFIG_USB=y >>>> CONFIG_USB_XHCI_HCD=y >>> > >
