Bootloader/flash question

[EricT]

I've gotten good help here before, so I thought I'd ask for some guidance on this so I start down the right path.  I am writing code for a device that uses an MCF5212.  The image I have created runs as I'd like, so now I need to take the next step - I need to write a bootloader that can pick one of two images stored in flash and transfer control to that image.  Essentially, the bootloader will be loaded at the start of the internal flash and the two images will be written further down in the flash.

I can start the bootloader with CodeWarrior's pre-generated code for the ColdFire, but I'm not sure how I transfer control to a particular section of flash and what things I will need to set up so that each of the images will run the same as they run now while they are the only images present.

Also, is there a convenient way to combine all of the images to be flashed into a single file that I can flash to the device all at once, or will I need to flash all three separately?

Thanks for any help you can give!

[normT]

EricT,

Did you get a final resolution to this question?  I'm tring to accomplish the same task using the MCF5274 processor.  Would you be willing to share your solution?

Regards,

normT

[EdProulx]

I have the very same issue with a ColdFire MCF52254 processor system. If you have arrived at your solution, as indicated by others, it would be greatly appreciated by many, if you would share the solution!

[mjbcswitzerland]

Hi

I am not sure exactly which part you are interested in but for the M5225X you can find can find a serial boot loader, a USB boot loader and an Ethernet boot loader in the uTasker project (optionally encrypted).

See the following:

- http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

- http://www.utasker.com/docs/uTasker/uTaskerV1.3_USB_Demo.PDF

- http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF

Regards

Mark

www.uTasker.com
- OS, TCP/IP stack, USB, device drivers and simulator for M521X, M521XX, M5221X, M5222X, M5223X, M5225X. One package does them all - "Embedding it better..."

[EricT]

I thought I'd get a bit more specific to see if anyone has an idea how to help me.  I have images that run on the MCF5212 today and I want to be able to have two of them in the flash at the same time.  When the device comes on, it would make a decision about which image to start up.

My question is about how to do this - is there a way to change the default of having the vector table start at address 0x00000?  Is there an easy way to set things up so that I can transfer control to one of the images and it will act as a self-contained program running as though it is the only image out there, unaware of the bootloader or the other image?

[sjmelnikoff]

You will always need some kind of startup code which runs from the main reset vector at address 0. However, it could be as simple as inspecting a configuration flag, and then jumping to one of the code blocks.

The main code that is running can then copy its own interrupt vector table into RAM, and point the VBR there, happily oblivious of the existence of any other software.

With regard to combining the images, it may be possible to splice together their S-record files (provided that they all occupy mutually exclusive areas of flash, which clearly they should). Each file will have an S7 (end of file) line at the end; all but the last one of the combined file need to be removed.

Steve.

[EricT]

Thanks for the reply - I have some follow-up questions:

1. Will I need to change the code and data to be position-independent?  Or are the values in the vector table already relative to the start of the image?

2. The default start-up function from the included code is below, and I wanted to ask about code positioning.  My assumption (and I haven't gotten it to work yet, so please let me know if I'm wrong) is that the bootloader would start up with essentially the same code and you would go through initialization of IPSBAR, FLASHBAR and RAMBAR.  After you're done with that, I would think you'd want to do the branching based on whatever flag had been set.  So, before moving sp into SRAM, the condition would be checked and there would be a jmp to the correct set of code which would pick up from that point.  Is that the right spot to step in and take control?

Thanks!

asm_startmeup:
_asm_startmeup:

    move.w    #0x2700,sr

    /* Initialize IPSBAR */
    move.l    #(___IPSBAR + 1),d0
    move.l    d0,0x40000000
   
    /* Initialize FLASHBAR: locate internal Flash and validate it */
    move.l    #(___FLASH + 0x21),d0
    movec d0,FLASHBAR

    /* Initialize RAMBAR1: locate SRAM and validate it */
    move.l    #(___SRAM + 0x21),d0
    movec d0,RAMBAR1

    /* Point Stack Pointer into SRAM temporarily */
    move.l    #__SP_INIT,sp
   
    /* Initialize mcf5282 periphs, etc */
    jsr        mcf5213_init

    jsr     ___call_static_initializers

    /* Relocate Stack Pointer */
    move.l    #__SP_INIT,sp

    /* Jump to the main process */
    jmp        main
   
    bra        .
    nop
    nop
    halt

[kef]

1. Regarding position independence. If you would need just a single image, then you could compile it for known absolute addresses. Also, if you know which image is to sit in low addresses and which in high addresses, then you can compile those images for known absolute destination addresses. But if you need any image to work from both locations, either low or high, then you need to compile it with position independent code option. Constant data in flash should be code relative. RAM data should be fixed addresses, not code relative,

Regarding vector tables. Vectors table entries are pointers to absolute locations. So if you use position independent images, then you should adjust your images vector table in RAM to point to valid locations.

2. It would be nice if you could make your images replacing bootloader image just writing to FLASHBAR. FLASHBAR granularity is 512k and that  way more than flash size.

I did a bootloader for MCF51QE128. It's not a 5212 but also coldfire :smileyhappy:. Yes, bootloader starts first and checks two conditions: 1) bootloader checks if image is loaded (the first longword of image isn't erased flash ==0xffffffff, also it could be some image checksum validation), 2) bootloader checks some more conditions (is button on the demoboard pressed, signaling I don't want to pass control to misbehaving image but load another one).

I compile my single image as absolute, but with code and vector table shifted up in memory by size of bootloader. Bootloader knows the address of images vector table and

         MOVE.L   (APP_START),D2             ; load images 0th vector, initial SP

                                                                    ; of the image
         CMP.L     #0xFFFFFFFF,D2              ; is it erased flash?
         BEQ.B     continue_with_bootloader  
         MOVEA.L  D2,SP                               ; image isn't erased, init images SP
         MOVE.L   (APP_START+4), A0         ; --jump to address pointed by 1st vector
         JMP         (A0)                                    ;  /
continue_with_bootloader

BTW it would be nice to preserve D0 and D1 registers until image starts. D0 and D1 after reset contain about coldfire version and about availability of mac, hw divider etc.

After I jump to the image, image copies its vector table to bottom of RAM, then image initializes VBR register to use vector table in RAM. Using position independent image you would need also to adjust vector table entries depending on absolute image position.

[ss1999]

Per your reply in forum, you did the bootloader for MCF51QE128. 

Do you mind to share the bootloarder code to me ? Thank you.

[EricT]

1. The images all need to be able to run from either position in memory - the images will be essentially the same, but will be different versions.  So it will ship with only one image (or with two duplicate images) and when we go through an update, we erase the second half of flash and write the updated image there and make that image the current one.  If we do another update, then we overwrite the first image and make that image the current one.  And so on.  This gives us redundancy so if an update fails, we can still use the previous version.  I guess I'll need to set up to use the position-independent code option.  So far, when I compile with that, I get a bunch of warnings in the format of ".pic__my_function_here(.picdynrel) in file function.c is referenced but has not been written".  And when I follow the help file directions to recompile the runtime library to allow for the position-independent code option, I get a ton of errors.  I'll just look at that - I'm sure there's something I'm just not doing quite right.

2. Yes, it would be VERY nice if I could have just adjusted FLASHBAR so that it would load up the vector table and image that I want as though it was located at 0x00000.  My problem would be already solved!    Since that doesn't work, I've been trying all kinds of combinations of things that haven't been working, but it's probably because I haven't been suing position-independent code.  Maybe it was working, but at some point in the code we get to a jump and it jumps back to the original image instead of staying within the second image.

So, in the code snippet you provided, do you do that before or after setting up IPSBAR, FLASHBAR and RAMBAR?

Thanks!

[bkatt]

---

Eric T wrote:
1. The images all need to be able to run from either position in memory - the images will be essentially the same, but will be different versions.  So it will ship with only one image (or with two duplicate images) and when we go through an update, we erase the second half of flash and write the updated image there and make that image the current one.  If we do another update, then we overwrite the first image and make that image the current one....

---

Our system works like this, using a small boot loader and 2 copies of the loadable firmware at different locations. Last summer I messed around with the PIC flags but could not get them to do what I needed. So we use normal code linked to absolute addresses, with all even numbered versions going into one location and odd numbered versions going into the other location.

The processors obviously support PIC, but the compilers and linkers seem to implement it for the purpose of library code rather than embedded firmware.

[kef]

I don't know how easy it is to use position independent code. A lack of precompiled PIC libraries tells something. I'll try using it some day.

I think bootloader should provide some functionality so that if bootload fails, then at least control shouldn't be passed to partially loaded image. Also bootloader should double check that it's a not mistake or comms failure and user really wants to suspend normal operation, erase the old image and upload new image to the chip. Having just a single image and bootloader in protected flash area, if bootload fails for example due to power failure, then we just bootload again; bootloader is always resident and available. You may have a nice concept with two images, but I don't see how it could be better than classic (I think) write/erase protected bootloader + single image.

And regarding code snippet. V1 (51QE128) doesn't have any xxxBAR register. If V1 had them, then I would try to avoid touching them. I prefer starting loaded image as if there was no bootloader, all registers in their default reset state, if possible.

My bootloader assumes that single image comes at address 0+sizeof(protected bootloader area). Initial supervisor SP and initial program counter do come first. Bootloader loads them to SP and jumps to PC. I decided that downloadable image is responsible to copy images exception table to RAM and init vector base register (VBR). Processor expert tends to initilaize VBR, so I'll try to feed it with VBR value I want. I'm just starting with Coldfire; it's possible I overlooked something.

Regards