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

Reply via email to