Re: Bootloader Placement

Tom Lucas wrote:

I have written a bootloader to reside in my first sector (128Kbyte) of flash which, firstly copies all code and data from flash to RAM and then checks data on an MMC card to see whether an update of the flash is necessary and, if so, copies new program data into the flash. At the moment I have two projects - the bootloader as a stand-alone loader and the full application, which has the bootloader code as part of it.

What I'd like to do is seperate the bootloader code from the application code and have the boot loader pass control to the application once it has done its checks and, if necessary, reprogramming. However, I don't think I could have the application as stand-alone code as well because it would then be re-initialising the hardware and memory of what was initialised previously in the bootloader.

My thoughts were to define the first flash sector as a seperate linker section and locate all the bootloader functions and data in there but as part of the application software. Then, when a reprogram takes place I just don't write to the first sector. The problem with that is that the old bootloader then does not know where to jump to in the application and also the copy from flash to RAM on startup won't know how much there is to copy. I only want to write to the bootloader area when the loader itself is to be updated because, if it fails, JTAG is the only recovery and that won't be available in the field.

There must be a better way of doing this but I'm not sure which direction to proceed.


The way I've seen to do this works best in a flash that can be protected sector-by-sector. Put the bootloader into the sector where your processor boots, and protect that sector. If necessary use multiple sectors, but it's a good idea to make bootloaders as small as possible. Set up the boot loader to _always_ branch to the beginning of the lowest unprotected sector once it detects application code, and _always_ load app code there.

To run stand-alone app code just replace the bootloader with a jump, or your minimal hardware setup and a jump.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/
.

Relevant Pages

  • Re: Bootloader Placement
    ... flash which, firstly copies all code and data from flash to RAM and then ... which has the bootloader code as part of it. ... code and have the boot loader pass control to the application once it has ... My thoughts were to define the first flash sector as a seperate linker ...
    (comp.arch.embedded)
  • Re: Bootloader Placement
    ... The bootloader would treat both of the others as ... It's an interesting thought but the bulk of the boot loader is an MMC card ... together as the flash loading part is so much smaller. ... Prefetch Abort exceptions and don't intend to include a handler so I could ...
    (comp.arch.embedded)
  • Re: More about ROMOFFSET usage.
    ... ROMOFFSET is used as a convenience to allow the image to be ... The bootloader then copies the the image in flash to RAM, ... Boot loader, image ...
    (microsoft.public.windowsce.embedded)
  • Re: What NAND flash is compatible with FAL?
    ... since FAL cannot use all optimizations present in OneNAND ... Basically a OneNAND is nothing else than a conventional NAND flash ... together the 64 bytes of spare area per page you have enough room to ... The FAL writes sector state information to the Flash device. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: What NAND flash is compatible with FAL?
    ... since FAL cannot use all optimizations present in OneNAND ... Basically a OneNAND is nothing else than a conventional NAND flash ... The FAL writes sector state information to the Flash device. ... spare spare area to record the FAL's state data. ...
    (microsoft.public.windowsce.platbuilder)