rk3399: SPI boot: Return from ROM unsuccessful (with TPL)

It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Jagan.

On Wed, May 20, 2020 at 5:39 PM Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Hi,
We have done the following changes and booted via SPI flash on roc-rk3399-pc and rockpro64-rk3399 targets.
U-Boot TPL 2020.07-rc2-00204-ge74f823-dirty (May 23 2020 - 23:18:34) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 spl_boot_device: Trying to boot from BOOTROM board_return_to_bootrom: Returning to boot ROM...
U-Boot TPL 2020.07-rc2-00204-ge74f823-dirty (May 23 2020 - 23:18:34) sdram_init: LPDDR4 - 50MHz failed! rk3399_dmc_init DRAM init failed -22 spl_boot_device: Trying to boot from BOOTROM board_return_to_bootrom: Returning to boot ROM...
for some reason, TPL loads twice. Unable to understand this behaviour. Any inputs ?
diff --git a/Makefile b/Makefile index 463fa72..167de36 100644 --- a/Makefile +++ b/Makefile @@ -1439,10 +1439,10 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
# rockchip image type -ifeq ($(CONFIG_SPL_SPI_LOAD),y) -ROCKCHIP_IMG_TYPE := rkspi -else +ifeq ($(CONFIG_SPL_MMC_SUPPORT),y) ROCKCHIP_IMG_TYPE := rksd +else +ROCKCHIP_IMG_TYPE := rkspi endif
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi index 141dd0b..a331d1a 100644 --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi @@ -11,8 +11,12 @@ spi0 = &spi1; };
+ config { + u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */ + }; + chosen { - u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc; + u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc; };
vcc_hub_en: vcc_hub_en-regulator { @@ -40,6 +44,12 @@ vin-supply = <&vcc_vbus_typec0>; };
+&spi1 { + spi_flash: flash@0 { + u-boot,dm-pre-reloc; + }; +}; + &vdd_log { regulator-min-microvolt = <430000>; regulator-init-microvolt = <950000>;
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index aff690f..7ae6789 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -7,12 +7,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 +CONFIG_SPL_SPI_LOAD=y CONFIG_TPL=y CONFIG_TPL_GPIO_SUPPORT=y CONFIG_CMD_BOOTZ=y

On 20 May 2020, at 13:08, Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Jagan.
In my experience when building the TPL and SPL image to be written to SPI flash, they both have to be processed by mkimage to generate an rkspi format image. The approach of using mkimage to produce the idbloader.img from the TPL and then simply concatenating the SPL at the end, which works for SD/eMMC boot images, doesn't work for SPI and it results in a similar error to what you reported, so that might be the cause?
I use the following command to generate the TPL+SPL image for SPI boot:
mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin spi_idbloader.img
On a rockpro64 board, the resulting spi_idbloader.img can be written to offset 0 in SPI flash, then when booting it the bootrom will start the TPL, TPL returns to bootrom and then bootrom will start the SPL.
There are some additional changes to the dts and config for rockpro64 needed to fully support SPL to load u-boot proper from SPI flash, I'll send patches for these changes.
Hugh.

On Sun, May 24, 2020 at 3:52 PM Hugh Cole-Baker sigmaris@gmail.com wrote:
On 20 May 2020, at 13:08, Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Jagan.
In my experience when building the TPL and SPL image to be written to SPI flash, they both have to be processed by mkimage to generate an rkspi format image. The approach of using mkimage to produce the idbloader.img from the TPL and then simply concatenating the SPL at the end, which works for SD/eMMC boot images, doesn't work for SPI and it results in a similar error to what you reported, so that might be the cause?
I use the following command to generate the TPL+SPL image for SPI boot:
mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin spi_idbloader.img
On a rockpro64 board, the resulting spi_idbloader.img can be written to offset 0 in SPI flash, then when booting it the bootrom will start the TPL, TPL returns to bootrom and then bootrom will start the SPL.
There are some additional changes to the dts and config for rockpro64 needed to fully support SPL to load u-boot proper from SPI flash, I'll send patches for these changes.
Hi Hugh,
I have used the above command as indicated by you for generating TPL+SPL. Flashed SPI flash using below commands from uboot prompt. Tested roc-rk3399-pc and rockpro64 targets.
bootrom loads TPL, TPL returns back to bootrom and then it hangs.
U-Boot TPL 2020.07-rc2-00204-ge74f823-dirty (May 25 2020 - 00:10:26) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 spl_boot_device: Trying to boot from BOOTROM board_return_to_bootrom: Returning to boot ROM... �𪩪r?SA�
SPI flash:
load mmc 1:1 $kernel_addr_r idbloader.img sf probe sf erase 0 +$filesize sf write $kernel_addr_r 0 ${filesize} load mmc 1:1 ${kernel_addr_r} u-boot.itb sf erase 0x40000 +$filesize sf write $kernel_addr_r 0x40000 ${filesize}
Thanks Suniel
Hugh.

On 24 May 2020, at 20:00, Suniel Mahesh sunil@amarulasolutions.com wrote:
On Sun, May 24, 2020 at 3:52 PM Hugh Cole-Baker sigmaris@gmail.com wrote:
On 20 May 2020, at 13:08, Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Jagan.
In my experience when building the TPL and SPL image to be written to SPI flash, they both have to be processed by mkimage to generate an rkspi format image. The approach of using mkimage to produce the idbloader.img from the TPL and then simply concatenating the SPL at the end, which works for SD/eMMC boot images, doesn't work for SPI and it results in a similar error to what you reported, so that might be the cause?
I use the following command to generate the TPL+SPL image for SPI boot:
mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin spi_idbloader.img
On a rockpro64 board, the resulting spi_idbloader.img can be written to offset 0 in SPI flash, then when booting it the bootrom will start the TPL, TPL returns to bootrom and then bootrom will start the SPL.
There are some additional changes to the dts and config for rockpro64 needed to fully support SPL to load u-boot proper from SPI flash, I'll send patches for these changes.
Hi Hugh,
I have used the above command as indicated by you for generating TPL+SPL. Flashed SPI flash using below commands from uboot prompt. Tested roc-rk3399-pc and rockpro64 targets.
bootrom loads TPL, TPL returns back to bootrom and then it hangs.
U-Boot TPL 2020.07-rc2-00204-ge74f823-dirty (May 25 2020 - 00:10:26) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 spl_boot_device: Trying to boot from BOOTROM board_return_to_bootrom: Returning to boot ROM... �𪩪r?SA�
SPI flash:
load mmc 1:1 $kernel_addr_r idbloader.img sf probe sf erase 0 +$filesize sf write $kernel_addr_r 0 ${filesize} load mmc 1:1 ${kernel_addr_r} u-boot.itb sf erase 0x40000 +$filesize sf write $kernel_addr_r 0x40000 ${filesize}
This could potentially be overwriting part of the idbloader.img - check that idbloader.img's filesize isn't over 0x40000 bytes. I've found that typically it can be about 320kB and so use 0x60000 as a safer value for u-boot,spl-payload-offset.
Thanks Suniel
Hugh.

On Mon, May 25, 2020 at 2:55 AM Hugh Cole-Baker sigmaris@gmail.com wrote:
On 24 May 2020, at 20:00, Suniel Mahesh sunil@amarulasolutions.com wrote:
On Sun, May 24, 2020 at 3:52 PM Hugh Cole-Baker sigmaris@gmail.com wrote:
On 20 May 2020, at 13:08, Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
Jagan.
In my experience when building the TPL and SPL image to be written to SPI flash, they both have to be processed by mkimage to generate an rkspi format image. The approach of using mkimage to produce the idbloader.img from the TPL and then simply concatenating the SPL at the end, which works for SD/eMMC boot images, doesn't work for SPI and it results in a similar error to what you reported, so that might be the cause?
I use the following command to generate the TPL+SPL image for SPI boot:
mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin spi_idbloader.img
On a rockpro64 board, the resulting spi_idbloader.img can be written to offset 0 in SPI flash, then when booting it the bootrom will start the TPL, TPL returns to bootrom and then bootrom will start the SPL.
There are some additional changes to the dts and config for rockpro64 needed to fully support SPL to load u-boot proper from SPI flash, I'll send patches for these changes.
Hi Hugh,
I have used the above command as indicated by you for generating TPL+SPL. Flashed SPI flash using below commands from uboot prompt. Tested roc-rk3399-pc and rockpro64 targets.
bootrom loads TPL, TPL returns back to bootrom and then it hangs.
U-Boot TPL 2020.07-rc2-00204-ge74f823-dirty (May 25 2020 - 00:10:26) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 spl_boot_device: Trying to boot from BOOTROM board_return_to_bootrom: Returning to boot ROM... �𪩪r?SA�
SPI flash:
load mmc 1:1 $kernel_addr_r idbloader.img sf probe sf erase 0 +$filesize sf write $kernel_addr_r 0 ${filesize} load mmc 1:1 ${kernel_addr_r} u-boot.itb sf erase 0x40000 +$filesize sf write $kernel_addr_r 0x40000 ${filesize}
This could potentially be overwriting part of the idbloader.img - check that idbloader.img's filesize isn't over 0x40000 bytes. I've found that typically it can be about 320kB and so use 0x60000 as a safer value for u-boot,spl-payload-offset.
Yes, but we are with in the limit, our idboader.img size is 124K (0x1F000)
# du -hs idbloader.img 124K idbloader.img
Jagan.

Hi Philipp,
On Wed, May 20, 2020 at 5:38 PM Jagan Teki jagan@amarulasolutions.com wrote:
It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful.
I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI.
SPI boot log:
U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM...
Any inputs?
It Looks like a puma is only a rk3399 board which boots from SPI in Mainline, just in case if you ever tried TPL flow or any inputs to look at it?
Jagan.
participants (3)
-
Hugh Cole-Baker
-
Jagan Teki
-
Suniel Mahesh