Second level Qi / shadow Qi for unbrickability? [was: Enable Qi / backup rootfs]

[Joerg Reisenweber]

I just had some cloudy idea of having 2 Qi loaders at different address 
levels.
Imagine your first attempt to flash Qi aborts prematurely (power failure etc).
You won't get a second chance to try :-(
If we route the below mentioned nWR signal to a addressline-exor as well, we 
might flash the shadow-Qi from normal linux system (yeah, right now nWR would 
block this as well), and this secondary "shadow"-Qi would be used instead 
of "first-level-Qi" when we hold this magic button on boot, due to action of 
exor-gate on A11-line or whatever size 2^n we decide. Secondary stays intact, 
even when flashing primary Qi fails - we could retry to flash primary Qi as 
often as we like, by just holding the magic button.
On success to flash primary we eventually could flash secondary Qi some time 
later on.

Again: it's just a cloudy idea! I like to hear some comments before I start to 
think more thoroughly about it.

cheers
jOERG



Am Sa  23. August 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> 
> | In all these cases, you could avoid using a boot parameter. But it's
> 
> No problem then.
> 
> |> that can't be handled in Qi update.
> |
> | But you don't want to have to update qi. Eventually, we want to treat
> | it like NOR, i.e., not even advanced users should have to update it.
> | That way, it can always be relied upon to boot the system.
> 
> This is the same debricking vs update argument that can only truly be
> answered by USB -> JTAG onboard the phone.  Lacking that, we should
> allow Qi update under special user action on GTA03 working through the
> nWP system and not lock users out -- although that's a power we have to
> take care about alright.  Users with debug board and Jtag can always
> override it anyway.  For GTA02, the NOR "backup bootloader" means we can
> update Qi how we like.
> 
> The nWP lock stuff on GTA03 just means the user gets final control over
> when he updates Qi, not that it is not routinely updateable.
> 
> |> Can you provide a link to where I made that "clear"?  Should be easy
> |> since you state it as a fact.
> |
> | Heh, I think I can tell by now when we reach the point in a
> | discussion where you dig in and will defend that position to
> | the knife ;-)
> 
> Didn't think I said such a thing.  As I explained contradicting your
> report of my opinions, kexec is okay by me, but it is a relatively small
> adjunct to having a backup kernel + rootfs rather than a cure for
> cancer.  If we use it to push the statefulness of the boot system out of
> the bootloader, that's a plus (although then we still need to plan where
> the decision to go into the backup filesystem by default is made, and
> that decision does occur at the bootloader).
> 
> | If you mean "shell and the usual utilities", then I'd agree that
> | we shouldn't be too stingy, since they're likely to be very well
> | tested and have reasonably low complexity. I'd even throw in a
> | very simple GUI, like the Petitboot we've already talked about.
> 
> What do we actually need this backup NAND fs for in the context that we
> can pop the SD Card and nuke the "system partition" in a PC?  What kind
> of functionality do we think about putting in there then?  I guess
> failsafe network access is good but it all seems secondary if you have
> direct access to the SD Card if surgery is needed.
> 
> -Andy
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080825/73c32bb3/attachment.pgp