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