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

[Kever Yang]

Hi Jonas,

On 2024/2/5 20: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.
>>>
>>> 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.
There are two case need to consider when hang() happen:
- For release version: a reboot and get into reset into bootrom download 
mode if boot fail more than 3 times;
- For debug version: a dump stack with hang() will be better(which is 
used in rockchip vendor u-boot);
Reboot to bootrom download when hang() happen is handy for U-Boot error 
happen, no need to press the reset
and recovery/download key in this case.
The final logic would be: fall back to usb boot(bootrom) whenever we 
fail to boot in to next stage,
so that we have chance to update an available firmware.

Thanks,
- Kever
>
> I am open for any suggestions.
>
> Regards,
> Jonas
>
>> Cheers,
>> Quentin