[REGRESSION] imx: spl_imx_romapi: boot loops

[Marcel Ziswiler]

Hi Rasmus

Thanks again.

On Tue, 2023-10-24 at 13:17 +0200, Rasmus Villemoes wrote:

[snip]
> 

> > 
> So this is interesting. I tried disabling CONFIG_IMX_HAB (because that
> case doesn't create an .itb with external data) and boot on a board
> which is not locked down, and I get
> 
> Trying to boot from BOOTROM
> Boot Stage: USB boot
> Find img info 0x000000004802df00, size 1504
> already have 256 bytes
> Need continue download 2048
> spl_romapi_read_stream(): ss->pagesize = 0x1
> spl_romapi_read_stream(): ss->pagesize = 0x1
> downloading another 0x9d768 bytes
> spl_romapi_read_stream(): rom_api_download_image -> 240
> spl_romapi_read_stream(): ss->pagesize = 0x1
> downloading another 0x1ff18 bytes
> spl_romapi_read_stream(): rom_api_download_image -> 240
> spl_romapi_read_stream(): ss->pagesize = 0x1
> spl_romapi_read_stream(): ss->pagesize = 0x1
> downloading another 0x1622 bytes
> spl_romapi_read_stream(): rom_api_download_image -> 240
> NOTICE:  BL31: v2.6(release):lf-5.15.71-2.2.0-0-g3c1583ba0-dirty
> NOTICE:  BL31: Built : 11:00:38, Nov 21 2022
> 
> and this works just fine. But in my case ss->pagesize is 1, whereas you
> have 512.
> 
> Just exactly how are you booting? It says "Boot Stage: Primary boot"
> whereas I'm doing serial download with uuu (i.e. "Boot Stage: USB boot").

Yes, regular eMMC boot. Serial download also works for me (note this requires a patch still not merged upstream
[1]):

U-Boot SPL 2024.01-rc1-00001-g36413e27727-dirty (Oct 24 2023 - 15:03:05 +0200)
Training FAILED
DDR configured as single rank
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: USB boot
Find img info 0x4802b000, size 1044
Need continue download 1024
spl_romapi_read_stream ss->pagesize 0x1
spl_romapi_read_stream ss->pagesize 0x1
downloading another 0xd6480 bytes
rom_api_download_image()=240
spl_romapi_read_stream ss->pagesize 0x1
downloading another 0x1ac70 bytes
rom_api_download_image()=240
spl_romapi_read_stream ss->pagesize 0x1
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.9(release):v2.9.0-619-g5f01b0b11
NOTICE:  BL31: Built : 11:08:02, Sep  6 2023


U-Boot 2024.01-rc1-00001-g36413e27727-dirty (Oct 24 2023 - 15:03:05 +0200)

CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)

[snip]

> It seems weird that you even end up in the is_boot_from_stream_device()
> if you're booting from eMMC (which would explain the 512 byte page size).

At least I am not aware that we would be doing anything special for eMMC boot.

> Also, the prints above reveal that the download of the 0x1ae00 succeeds,
> but then we enter the function once more, and for some reason your
> printf() gets cut short; in my boot, that's for fetching another 0x1622
> bytes. My guess is that the board hangs because it tries to download
> more data than the stream can supply, due to the rounding-up to
> ss->pagesize. Can you try with this
> 
> diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi
> b/arch/arm/dts/imx8mp-u-boot.dtsi
> index e54df1766fa..4b5e9ff466f 100644
> --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> @@ -100,6 +100,7 @@
> 
>         itb {
>                 filename = "u-boot.itb";
> +               align-size = <512>;
> 
>                 fit {
>                         description = "Configuration to load ATF before
> U-Boot";
> 
> so that u-boot.itb is extended so it's a multiple of 512 bytes?

Unfortunately, that did not help. I mean it does make the u-boot.itb a multiple of 512 but keeps crashing the
exact way as before.

> Rasmus

[1] https://lore.kernel.org/all/20230828213803.454303-1-marcel@ziswiler.com

Cheers

Marcel