• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 3389 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Custom Bootloader Query

Alistair Lowe
Note: This was originally posted on 13th September 2012 at http://forums.arm.com

Hi guys,

I'm currently writing the code for a custom bootloader for a Cortex-M0 and am tripping over myself a little with memory allocation.
From what I gather with the ARM compiler, globals and statics head into RW CODE space, not on the stack.

In my situation, I have a two stage bootloader and application code.

I'm guessing I'll have to reserve space for any globals so that the second stage doesn't overwrite anything in the first stage, my question then is, when branching from my first stage to the second stage, what's the best way to deal with the stack pointer? I'll still be using the main stack at this point.

To elaborate a little further, right now it's feeling simplest to reserve some space in RAM and then assign the same stack details to each bootloader and use only stack memory and link into the reserved memory through pointers.

It would be ideal for maintainence/clarity if there was a way to use standard globals and statics as opposed to having to leave RAM free to tie into later on, whilst not having the two bootloader stages step on each other's toes.



Does anyone have any recommendations or suggestions of approaches that they've tried before and gotten along with?

Many thanks
Parents
  • Note: This was originally posted on 13th September 2012 at http://forums.arm.com


    Presumably the two stages are compiled independently, and the first doesn't remain resident (or offer any services) after it hands control over to the second. At that point, surely it doesn't matter if the RW, heap and stack of the second overlap with the first? It would appear that all the first needs to do is set the MSP to the top-of-RAM, and BX into the second stage.

    s.


    Sorry, in this situation the first does remain partially resident, offering flashing functionality.

    In short:

    Stage one = management of dual images to protect from flash corruption, exposing flashing commands to stage two.
    Stage two = implementation of X protocol for remote flashing.

    As X protocol may change in the future, the system is designed so that the second stage can be re-flashed without risking a full brick, otherwise this would be a standard one stage system. It's not a two-stage bootloader in  the same sense linux would use one.
Reply
  • Note: This was originally posted on 13th September 2012 at http://forums.arm.com


    Presumably the two stages are compiled independently, and the first doesn't remain resident (or offer any services) after it hands control over to the second. At that point, surely it doesn't matter if the RW, heap and stack of the second overlap with the first? It would appear that all the first needs to do is set the MSP to the top-of-RAM, and BX into the second stage.

    s.


    Sorry, in this situation the first does remain partially resident, offering flashing functionality.

    In short:

    Stage one = management of dual images to protect from flash corruption, exposing flashing commands to stage two.
    Stage two = implementation of X protocol for remote flashing.

    As X protocol may change in the future, the system is designed so that the second stage can be re-flashed without risking a full brick, otherwise this would be a standard one stage system. It's not a two-stage bootloader in  the same sense linux would use one.
Children
No data