01:15 <marex> calebccff: if the nonfree blob is not running, it cannot impose any undesired limitations/restrictions on the next stage

01:15 <marex> calebccff: if the next stage can start the blob e.g. because Linux needs its services, that is the choice of that next stage

01:18 <marex> the next stage can also decide which blob to start, if there are multiple, which can be scripted too

01:18 <marex> this may be the case for A/B update scenario

01:30 <calebccff> marex: riight, but if we ship a product that runs u-boot in EL3 and supports fastboot, and there's some exploit to get code execution then one could feasibly hard-brick a device by e.g. blowing fuses that are only accessible in EL3

11:15 <marex> calebccff: maybe what is needed is SPL which starts U-Boot in either EL2 or EL3 as needed by the integrator ?

11:15 <marex> calebccff: basically the kind of thing you did suggest with mini last time ?

11:15 <marex> calebccff: except with flexibility for integrators, i.e. give them a choice

17:21 <calebccff> marex: having a fancier PSCI implementation in U-Boot would be cool indeed

17:22 <calebccff> it would require teaching U-Boot to consider that it might be running code on multiple CPU cores at once though heh

19:49 <marex> calebccff: that's what the bakery lock in TFA is for, right ?