Re: Making Neo Brickproof, was comments after reading Wiki
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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Hi folks, I would strongly support putting a no-way-writable ROM chip as this first level boot loader. If there is no such option, I really wonder what is my option if somehow it gets screwed up, other than the trash can? Is there an always working solution to reset my moko? Emre Turkay On 5/17/07, Werner Almesberger [EMAIL PROTECTED] wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-) 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 -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Just had a further thought about what to do if the main bootstrap loader gets trashed that maybe easier to implement. Rather than a stage 1 bootstrap loader looking to the USB interface for a replacement how about looking on the SD card? Simon On Thu, 2007-05-17 at 01:58 -0300, Werner Almesberger wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-) 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Making Neo Brickproof, was comments after reading Wiki
JTAG, via the debug port. From: [EMAIL PROTECTED] on behalf of Emre TurkaySent: Thu 5/17/2007 5:25 AMTo: community@lists.openmoko.orgSubject: Re: Making Neo Brickproof, was comments after reading Wiki Hi folks,I would strongly support putting a no-way-writable ROM chip as this first level boot loader. If there is no such option, I really wonder what is my option if somehow it gets screwed up, other than the trash can? Is there an always working solution to reset my moko?Emre Turkay On 5/17/07, Werner Almesberger [EMAIL PROTECTED] wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-)We rejected it, because we don't want to have yet more codeduplicating functionality found elsewhere to maintain. Besides, itwouldn't be all that trivial, given that we don't have any "simple" interfaces. (Anything that needs a debug board or other fancyadapters doesn't count.)Also, there really isn't much difference between a few protectedbytes or hundreds of protected kilobytes. We need an extra chip anyway, and if we want something reasonably small and modern, it'llhave 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--_/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] //_http://www.almesberger.net//___OpenMoko community mailing listcommunity@lists.openmoko.orghttp://lists.openmoko.org/mailman/listinfo/community NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: I would have thought it would be nice to avoid an extra chip. Yeah, we tried, but it just doesn't seem to be possible :-( There are some alternatives, but they then lead to other problems, such as chips not being available in quantity, etc. (And we've had our number of surprises with that. Once bitten, ...) Of course this [OTP} would only be any good if it could be mapped to the addresses that get downloaded by the CPU before it starts. That's in NAND Flash, which isn't really mapped. Instead, you transfer data in pages. So it's more like a disk than RAM. The MCU has a build-in boot loader that does this, but it doesn't know about OTP. Besides, that OTP can still be changed. 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. No, I don't think this will be needed. The basic recovery functions will be exercised well enough. To the contrary, since this is code we already use daily, it's more likely to be correct than a special-purpose loader that only gets used rarely. Even better: a more general recovery loader will give you more than one way to do things (e.g., SD card and USB), so even if one method fails, you still have a backup. 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. You'd have to ask Harald for comments on USB (among other things, he implemented DFU in u-boot), but my impression is that it's hard and messy enough that nobody wants to maintain yet another stack. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
On Thu, 2007-05-17 at 09:19 -0300, Werner Almesberger wrote: Yeah, we tried, but it just doesn't seem to be possible :-( There are some alternatives, but they then lead to other problems, such as chips not being available in quantity, etc. (And we've had our number of surprises with that. Once bitten, ...) If you do find a chip with a small protected page i might be interested in writing the loader i have outlined. will be exercised well enough. To the contrary, since this is code we already use daily, it's more likely to be correct than a special-purpose loader that only gets used rarely. As long as the bootstrap code reprogramming is bullet proof or you don't see the need for changing the boot code i can't see any problems with one large bootstrap. You'd have to ask Harald for comments on USB (among other things, he implemented DFU in u-boot), but my impression is that it's hard and messy enough that nobody wants to maintain yet another stack. I looked at using USB a few years ago and decided it was too convoluted and complex. IMHO a powered Ethernet variant would have been a much better arrangement that the USB mess. Regards Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: If you do find a chip with a small protected page i might be interested in writing the loader i have outlined. Thanks ! As long as the bootstrap code reprogramming is bullet proof or you don't see the need for changing the boot code i can't see any problems with one large bootstrap. Yes, that emergency bootstrap should be both bulletproof and immutable (with very few exceptions), but you have basically the same code also in the part of the system that is meant to be easily upgradeable, so even development that's very close to the hardware doesn't need to touch the recovery stuff. Perhaps a good analogy would be the recovery CD one may have for a PC. (Only that PC hardware can change a lot more than what's in a given phone. About the worst that could happen is that it may not recognize your brand-new 1TB uSD card, so you'd have to find one of the old and boring 4GB ones, or use USB :-) I looked at using USB a few years ago and decided it was too convoluted and complex. IMHO a powered Ethernet variant would have been a much better arrangement that the USB mess. Yeah, USB is a fine triumph of NIH. And of course, they had to add isochronous transmissions. That's to low-level communications about what the video phone is to telephony :-( - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-) 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 -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community