On 2024-02-06 03:25, Kever Yang wrote:
On 2024/2/5 20:34, Jonas Karlman wrote:
On 2024-02-05 11:49, Quentin Schulz wrote:
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.
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.
Just as a note, falling back to BROM may actually introduce some
security issues in some setups, by allowing rather low-level access
to the system that may not be desired.
Perhaps not enabling the fallback to BROM by default and leaving it
to the board configurations would be the desired way to move forward.
