Hi Jonas, On Sun, 9 Feb 2025 at 08:39, Jonas Karlman <jo...@kwiboo.se> wrote: > > Hi Simon, > > On 2025-02-09 15:27, Simon Glass wrote: > > Hi Jonas, > > > > On Wed, 5 Feb 2025 at 09:06, Jonas Karlman <jo...@kwiboo.se> wrote: > >> > >> Hi Simon, > >> > >> On 2025-02-05 02:55, Simon Glass wrote: > >>> Add support for this new phase, which runs after TPL. It determines the > >>> state of the machine, then selects which SPL image to use. SDRAM init is > >>> then done in SPL, so that it is updatable. > >> > >> I am still unsure how this makes it more updatable, what happen when > >> DRAM init fails and board freezes? Are we relying on e.g. a watchdog to > >> properly reset a frozen board and try next image? > > > > Yes, that's right. Also, when you do an upgrade you are not changing > > the only copy, thus avoiding bricking devices with a bad or partial > > update. > > Yes, it is unfortunate that the older Rockchip SoCs BootROM does not do > hash/checksum validation, thankfully the newer SoCs does, so for newer > SoCs it is more likely that bad code brick your device instead of a bad > or partial update. > > Also, Rockchips "Flash Open Source Solution Developer Guide" even > recommend to write multiple idblock headers to flash storage, this may > be something that we should consider. Typically, Rockchip BootROM will > check 5 positions in MMC for a valid idblock. > > Is there some code that configures a watchdog or similar that can help > unfreeze due to a bad code update using this?
Not yet, but it would be nice to have. [..] Regards, Simon
