Making Neo Brickproof, was comments after reading Wiki

Simon Matthews s.matthews at karrak.id.au
Thu May 17 10:38:41 CEST 2007


I would have thought it would be nice to avoid an extra chip. I noticed
after a quick scan through the documentation on the flash currently
being used by the Neo that there is one 16K block of OTP memory. Of
course this would only be any good if it could be mapped to the
addresses that get downloaded by the CPU before it starts.

I see a couple of problems with having one large complex bootloader. If
it is large and complex there is more chance it will need to be changed
due to changes in functionality or bugs. Each time it is changed you
have a chance of bricking the device, either by the code not programming
correctly or the code being wrong. If you always have a small stage 1
bootloader in place you can circumvent these problems.

Regarding the "simple interface", i agree that having an asynchronous
serial interface (RS232) that goes to the outside world would be nice,
but wonder how hard it would be to write a very basic USB driver with
just enough functionality to do the job of downloading some fixed format
data from a host. On the host side a simple program that can download
data to a USB slave device would all that would be needed.  From a user
perspective it should be kept as simple as possible so if the main
bootloader gets screwed up for whatever reason it would be nice to just
plug it into your computer and execute a simple program to restore it.

Simon


On Thu, 2007-05-17 at 01:58 -0300, Werner Almesberger wrote:


> We rejected it, because we don't want to have yet more code
> duplicating functionality found elsewhere to maintain. Besides, it
> wouldn't be all that trivial, given that we don't have any "simple"
> interfaces. (Anything that needs a debug board or other fancy
> adapters doesn't count.)
> 
> Also, there really isn't much difference between a few protected
> bytes or hundreds of protected kilobytes. We need an extra chip
> anyway, and if we want something reasonably small and modern, it'll
> have plenty of space. Thus there's no penalty in using it.
> 
> But yes, the "small loader" approach works well enough in other
> contexts. I've used it myself.
> 
> - Werner
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070517/5c85bb1a/attachment.htm 


More information about the community mailing list