[RFC] rockchip: Reset to bootrom download mode on hang

[Jonas Karlman]

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 <jonas at 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