u-boot/board/keymile
Aleksandar Gerasimovski 987b182830 km/ls102xa: use unused scratchrw4 address for post word
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>
2022-02-01 15:08:07 +05:30
..
common km: common: implement field fail-safe u-boot update 2022-02-01 15:08:07 +05:30
km83xx board/km: update MAINTAINERS files 2021-10-14 19:45:07 -04:00
km_arm board/km: update MAINTAINERS files 2021-10-14 19:45:07 -04:00
kmcent2 CONFIG_SYS_CLK_FREQ: Consistently be static or get_board_sys_clk() 2021-12-27 16:20:18 -05:00
pg-wcom-ls102xa km/ls102xa: use unused scratchrw4 address for post word 2022-02-01 15:08:07 +05:30
scripts km/scripts: fix saveenv command syntax 2021-06-17 11:46:11 +05:30
secu1 board/km: update MAINTAINERS files 2021-10-14 19:45:07 -04:00
Kconfig km: common: implement field fail-safe u-boot update 2022-02-01 15:08:07 +05:30
README km: common: implement field fail-safe u-boot update 2022-02-01 15:08:07 +05:30

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.