Making Neo Brickproof, was comments after reading Wiki
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, can be protected and will either jump to the main bootstrap loader if it is functional or be able to download a new 2nd stage bootstrap loader and program it into flash via the USB port. Here is a flow chart for the proposed loader RESET 1. Turn protection on for this first level bootstrap code (if necessary) 2. Check if user wants to download new 2nd stage bootstrap (could use AUX button), if so goto 5 3. Check if 2nd stage bootstrap exists (is 2nd stage bootstrap flash blank?), if so goto 5 4. Check 2nd stage bootstrap code in Flash via checksum, if OK load into RAM and jump to else goto 5 5. Download new second stage bootstrap image from the USB port and store into FLASH. I would use some simple HEX format like Intel or Motorola HEX format. I have used a similar scheme for some time now and it has been bullet proof for me. Simon Matthews On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: Marcin Wiacek wrote: Of I see that we think about different things Yup :-) I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. - 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
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
Making Neo Brickproof, was comments after reading Wiki
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, can be protected and will either jump to the main bootstrap loader if it is functional or be able to download a new 2nd stage bootstrap loader and program it into flash via the USB port. Here is a flow chart for the proposed loader RESET 1. Turn protection on for this first level bootstrap code (if necessary) 2. Check if user wants to download new 2nd stage bootstrap (could use AUX button), if so goto 5 3. Check if 2nd stage bootstrap exists (is 2nd stage bootstrap flash blank?), if so goto 5 4. Check 2nd stage bootstrap code in Flash via checksum, if OK load into RAM and jump to else goto 5 5. Download new second stage bootstrap image from the USB port and store into FLASH. I would use some simple HEX format like Intel or Motorola HEX format. I have used a similar scheme for some time now and it has been bullet proof for me. Simon Matthews On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: Marcin Wiacek wrote: Of I see that we think about different things Yup :-) I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. - 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
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
