mirror of
https://github.com/u-boot/u-boot.git
synced 2024-11-27 06:04:40 +08:00
987b182830
The SCRATCHRW4 is only used in secure boot scenario that is unsupported by our design, so this address can be stolen for storing POST status. The SCRATCHRW4 is initialized to zero at core rest. Using a DDR address was unfortunate choice, the DDR at boot time has a random contend and it happens that sometimes is matching POST magic number. This behavior can lead to undefined POST behavior and u-boot ending in failbootcmd command. Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachienergy.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com> |
||
|---|---|---|
| .. | ||
| common | ||
| km83xx | ||
| km_arm | ||
| kmcent2 | ||
| pg-wcom-ls102xa | ||
| scripts | ||
| secu1 | ||
| Kconfig | ||
| README | ||
Field Fail-Save U-boot Update ----------------------------- Field Fail-Save u-boot update is a feature that allows save u-boot update of FOX and XMC products that are rolled out in the field. The feature is initially implemented for designs based on LS102x SoC, but in theory can be used on all designs that are booting from parallel NOR flash. The implementation expects redundant (secondary) u-boot image on a predefined location in the NOR flash, u-boot execution will be transferred to the redundant (secondary) u-boot and redundant u-boot will be started if 'updateduboot' envvar is set to 'yes'. Update logic check_for_uboot_update() has to be invoked from the design early before relocation just after SoC initialization, e.g from board_early_init_f or misc_init_f functions. By design it is expected that primary u-boot image is burned in the factory and never updated, and in case u-boot update is required it can flashed and started from secondary u-boot location.