please don't switch to kexec (was Re: R70/R71 on debug v3 board ?)

Andy Green andy at
Mon Feb 11 12:36:27 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> On Mon, Feb 11, 2008 at 10:01:49AM +0000, Andy Green wrote:
>>> Anything that can be done in software is not a sufficient level of
>>> protection.  We want to reliably claim that this nor flash is read-only,
>>> and that users can always recover, no matter what they do on the
>>> software side.
>> How about if it doesn't ship with flash_unlock?
> no. it's still very easily possible for malicious code to circumvent that.

Well, if it can get in the phone and run as root, yes.

>>> In fact, the NOR flash is only for users who don't have a debug board.
>>> Users that have a debug board can always recover via jtag.  So making
>>> this dependent on the debug board is a perfect solution.
>> I can see the logic, but I can also see it puts us in a unique position
>> with it for the next couple of weeks until RTM, we're not going to be
>> able to generally update whatever it is we put in there subsequently.
> Well, that is the whole point :)  the nor u-boot must be finished for
> emergency boots before shipping the product.

It seems Werner has that much working, so that end of the existing plan
is okay.

>> That's annoying because it seems soon we will discard U-Boot and move to
>> using a kexec-ed kernel directly (thus getting out of this crazy system
>> of implementing things twice once for kernel and once for U-Boot).  And
>> we have 2MByte NOR there that can do this.
> I know werner has been wanting to do that for a long time.  But this
> really sucks.  Do you realize that you are just scrapping the ability to 
> boot any different OS on the device?

No I don't think so -- Linux can just be a large U-Boot for these
purposes, like Two Kernel Monte:

> It's supposed to be an open device.  Open not only in a way that you can
> write your own apps, but open also in the way that you can hack the OS.
> That you can in fact replace the OS, and run e.g. the (for GTA01
> existing) NetBSD port.  There might be more 
> Do you really believe this is the right step for an _open_ device?

I believe that U-Boot is just a broken down Linux, so logically if we
use the full-strength original actual Linux we can do a *superset* of
what was possible with U-Boot, including acting as a bootloader for BSD
or whatever.  There's nothing especially smelly about Linux for this
purpose (except footprint, but we have the space) that can't be said
about U-Boot the same.  It's just U-Boot modestly says it is a
"bootloader" and Linux says it is an "operating system".

>> We can recover a bricked device with the debug board, it seems to me we
>> take so much care avoiding the one scenario we create a problem along
>> with definitively fixing the possibility of corruption and that has to
>> be balanced.
> _we_ can.  We are the 'elite' who has those boards. In the future, 99.9%
> of all users will not have a debug board.  What is the RMA strategy for
> people who accidentially bricked their devices?  Where are the OpenMoko
> support centers in every major country that can do such a thing after
> sending in the device (without having to care about customs and
> excessive intercontinental shipping fees, ...)?  Who is going yo pay for
> it?

If the problem we're trying to solve is evil haxxors, then I guess we
should keep the hardware gating for NOR write: it truly limits what can
be done... otherwise we should allow NOR upgrades because it's hard
enough to brick already.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list