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

[Harald Welte]

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.

> > 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.

> 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?

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 

By switching to Linux-only, OpenMoko would show the same ignorance to
the user that other vendors show towards Linux.

Openness != Linux-ness.  Openness means standardization, abstraction,
known/documented interfaces, etc.  And it also means that the user is
open to run whatever OS on the device.

By switching to kexec, you virtually remove that ability.  Yes, people
can still replace the linux kernel with a bootloader, but it is _MUCH_
harder since you have to do all the low-leve setup such as GPIO
configuration, etc. again.  A common bootloader for PLL/GPIO init helps
a lot in that regard.

Also, dual-booting different OS's is no longer possible.

Do you really believe this is the right step for an _open_ device?

> 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?

Cheers,

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone