Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
On 2024/3/2 23:28, 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
What is the flash chip on this board? Does it a GigaDevice device?
This sound like some code address affect if your board has a flash chip
other than GigaDevice.
:
U-Boot SPL 2024.04-rc3-2-g06b486900e2 (Mar 02 2024 - 13:20:45 +)
Trying to boot from SPI
load_simple_fit: Skip load 'atf-5': image size is 0!
initcall failed at call 0029beec (err=-11: Try again)
### ERROR ### Please RESET the board ###
This is possibly because of pinctrl no being configured in SPL.
The pinctrl issue should affect all the SPI flash type, add GigaDevice
driver should not able to fix
this issue.
Thanks,
- Kever
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.
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 +)
SoC: Rockchip rk3399
Reset cause: unknown reset
Model: Radxa ROCK Pi 4A
DRAM: initcall failed at call 00228efc (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].
[2]https://github.com/Kwiboo/u-boot-rockchip/compare/2011cf069a8b...9767374d6a8a
[3]https://patchwork.ozlabs.org/cover/1900376/
Signed-off-by: Christopher Obbard
---
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", _flash, ,
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.
+ };
+};
+
+ {
+ spi_flash: flash@0 {
+ bootph-all;
+ };
+};
diff --git a/configs/rock-pi-4-rk3399_defconfig
Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
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-2-g06b486900e2 (Mar 02 2024 - 13:20:45 +) Trying to boot from SPI load_simple_fit: Skip load 'atf-5': image size is 0! initcall failed at call 0029beec (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 +) > board_spl_was_booted_from: brom_bootdevice_id 3 maps to > '/spi@ff1d/flash@0' > Trying to boot from SPI > rockchip_rk3288_spi spi@ff1d: spi_find_chip_select: plat=3ef8a80, cs=0 > jedec_spi_nor flash@0: from 0x000e, len d > jedec_spi_nor flash@0: from 0x000e, 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
Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
Hello 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:
It should be useful to also enable CONFIG_SPI_FLASH_MACRONIX, to allow
a broader choice for the people who will need to find an SPI chip and
solder it to the board they own.
- `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-2-g06b486900e2 (Mar 02 2024 - 13:20:45
+)
Trying to boot from SPI
load_simple_fit: Skip load 'atf-5': image size is 0!
initcall failed at call 0029beec (err=-11: Try again)
### ERROR ### Please RESET the board ###
Hmm, that's quite strange. Though, having CONFIG_SPI_FLASH_GIGADEVICE
enabled is actually useful, for the same reason as explained above.
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
+)
SoC: Rockchip rk3399
Reset cause: unknown reset
Model: Radxa ROCK Pi 4A
DRAM: initcall failed at call 00228efc (err=-19: No such
device)
### ERROR ### Please RESET the board ###
Signed-off-by: Christopher Obbard
---
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", _flash, ,
+ };
+};
+
+ {
+ 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=0x0020
CONFIG_NR_DRAM_BANKS=1
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
+CONFIG_SF_DEFAULT_SPEED=1000
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=0x40
CONFIG_DEBUG_UART_BASE=0xFF1A
CONFIG_DEBUG_UART_CLOCK=2400
+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=0x4
CONFIG_SPL_PAD_TO=0x7f8000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x40
@@ -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=0x1
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0xE
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
Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
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-2-g06b486900e2 (Mar 02 2024 - 13:20:45 >>> +) >>> Trying to boot from SPI >>> load_simple_fit: Skip load 'atf-5': image size is 0! >>> initcall failed at call 0029beec (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. 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 +) board_spl_was_booted_from: brom_bootdevice_id 3 maps to '/spi@ff1d/flash@0' Trying to boot from SPI rockchip_rk3288_spi spi@ff1d: spi_find_chip_select: plat=3ef8a80, cs=0 jedec_spi_nor flash@0: from 0x000e, len d jedec_spi_nor flash@0: from 0x000e, 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@fe33 spl_decode_boot_device: could not find udevice for /mmc@fe32 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 0xff8c 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. > >> >> BROM will only configure
Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
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-2-g06b486900e2 (Mar 02 2024 - 13:20:45
> > +)
> > Trying to boot from SPI
> > load_simple_fit: Skip load 'atf-5': image size is 0!
> > initcall failed at call 0029beec (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 ;-).
>
> 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 +)
> > SoC: Rockchip rk3399
> > Reset cause: unknown reset
> > Model: Radxa ROCK Pi 4A
> > DRAM: initcall failed at call 00228efc (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.
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
> > ---
> >
> > 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", _flash,
> > ,
>
> 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
Re: [PATCH v1 2/2] rockchip: rock-pi-4-rk3399: Enable booting from SPI flash
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-2-g06b486900e2 (Mar 02 2024 - 13:20:45 +)
> Trying to boot from SPI
> load_simple_fit: Skip load 'atf-5': image size is 0!
> initcall failed at call 0029beec (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.
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 +)
> SoC: Rockchip rk3399
> Reset cause: unknown reset
> Model: Radxa ROCK Pi 4A
> DRAM: initcall failed at call 00228efc (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].
[2]
https://github.com/Kwiboo/u-boot-rockchip/compare/2011cf069a8b...9767374d6a8a
[3] https://patchwork.ozlabs.org/cover/1900376/
>
> Signed-off-by: Christopher Obbard
> ---
>
> 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", _flash, ,
>
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.
> + };
> +};
> +
> + {
> + 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=0x0020
> CONFIG_NR_DRAM_BANKS=1
>
