Hi Quentin, On 2024-02-05 11:49, Quentin Schulz wrote: > Hi Jonas, > > On 2/2/24 01:12, Jonas Karlman wrote: >> Add support to reset to bootrom download mode on hang in U-Boot SPL and >> proper. ROCKCHIP_HANG_TO_BROM can be used to enable this feature. >> >> Example when SPL cannot load FIT: >> >> U-Boot SPL 2024.04-rc1 (Feb 01 2024 - 23:01:12 +0000) >> Trying to boot from MMC1 >> mmc_load_image_raw_sector: mmc block read error >> Trying to boot from MMC2 >> Card did not respond to voltage select! : -110 >> spl: mmc init failed with error: -95 >> Trying to boot from MMC1 >> mmc_load_image_raw_sector: mmc block read error >> SPL: failed to boot from all boot devices >> ### ERROR ### Please RESET the board ### >> entering download mode ... >> resetting ... >> >> Procedure to start bootrom download mode: >> - U-Boot SPL or proper write 0xEF08A53C to BOOT_MODE_REG and then reset >> - Bootrom loads and run boot code (TPL) from e.g. SPI > eMMC > SD-card >> - TPL check for 0xEF08A53C in BOOT_MODE_REG very early, i.e. Rockchip >> TPL blobs check for this value directly at start >> - TPL return to bootrom with a return value != 0 >> - Bootrom enter download mode >> >> This also fixes an issue where the BOOT_MODE_REG is reset to 0 when >> board is reset on RK35xx after TF-A has been loaded. To fix this the >> SOC_CON1 reg value is reset prior to issuing a global reset. >> >> The RK356x TF-A blobs will clear SOC_CON1 as part of a PSCI reset, >> however the RK3588 TF-A blobs does not seem to clear SOC_CON1. >> >> Signed-off-by: Jonas Karlman <jo...@kwiboo.se> > > I'm wondering if there isn't a simpler way to do this? > > board_boot_order() could parse u-boot,spl-boot-order for e.g. "bootrom", > the same way it does for "same-as-spl" for example. > > If it is set, then add BOOT_DEVICE_BOOTROM to spl_boot_list. > > Then this would call spl_return_to_bootrom() from > common/spl/spl_bootrom.c which in turns would call > board_return_to_bootrom() and back_to_bootrom(). > > What do you think?
Something like that is what I did in my initial implementation :-) I appended a BOOT_DEVICE_BOOTROM at the end of board_boot_order() and implemented necessary parts in spl_return_to_bootrom(), and that worked great for SPL. However, to catch a hang() in U-Boot proper, e.g. a failed initcall, the only existing integration callback for hang() is to override show_boot_progress(). Because the use of show_boot_progress() worked for both SPL and U-Boot proper (probably also TPL) it seemed better to only have one integration part for all phases. I am still not sure exactly when we would want to fall back into bootrom download mode. Always at a hang() or at controlled parts e.g. when no FIT can be loaded. I am open for any suggestions. Regards, Jonas > > Cheers, > Quentin
