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

[Eugen Hristev]

Hello Jonas,

On 2/5/24 14:34, Jonas Karlman wrote:
> 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.

Recently I tested BL31 with TF-A, it works, and you can send a patch to fix bugs in
there if you find them !
Its open source, I gathered the patches and tested them here:

https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a

>>>
>>> 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.

I implemented DFU in SPL at some point last year (due to DWC3 being unaligned with
Linux the patches weren't accepted), and defaulting to DFU is also an option when
nothing boots.

(
https://patchwork.ozlabs.org/project/uboot/cover/20230801072811.10354-1-eugen.hristev@collabora.com/#3185956
)

Eugen
> 
> Regards,
> Jonas
> 
>>
>> Cheers,
>> Quentin
>