Keil Logo

Change load region at runtime

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Author
Ronen Wino
Posted
2-Oct-2017 11:16 GMT
Toolset
ARM
New! Change load region at runtime

Hi All,

I am implementing a software upgrade mechanism (burning a new image into a flash memory area).

The problem:
I don't know how to change the load region address at runtime.

Flash contains booter and application
Additionally I allocated an area for new sw application on the same flash.
After burning the new sw into the allocated area on the flash,
I want to run the new sw instead of the old one.

Booter already knows how to jump to the new code in the flash.
The problem is that new and old code are both compiled with the same
scatter loading region mapping, so when i run the new code
from the new address it still uses the "old" scatter loading region,
i.e. it loads my old code.

Is there a way of setting the LR address to be relative and not absolute.

Of course i can compile the new SW with new scatter mapping, but this doesn't help me, because i don't know if it will run as a "new" or "old" image.

Thanks in advance

Author
Westonsupermare Pier
Posted
2-Oct-2017 15:56 GMT
Toolset
ARM
New! RE: Change load region at runtime

You'd need to use an object file format with relocation information. ELF (AXF) has such a format, but you might want to create your own minimally complicated version.

This is basic linker/loader stuff, should be covered in college level classes.

For Cortex-Mx implementations the biggest issue is absolute addresses in the Vector Table, if the rest of your code is Position-Independent, then you just need to fix up the vectors as you write to a new memory area.

Author
Ronen Wino
Posted
3-Oct-2017 04:03 GMT
Toolset
ARM
New! RE: Change load region at runtime

Hi,

I will try to re-explain my question:
I would like to be able to dynamically change my load region "base_address" as given through my scatter-loading definition.

Thanks,
Ronen

Author
Ronen Wino
Posted
3-Oct-2017 09:17 GMT
Toolset
ARM
New! RE: Change load region at runtime

Hi,

I would like to rephrase my question.

I’m using arm926ej-s chip which has a three steps boot sequence:
1st step - Primary bootloader (I call it “ROM Boot”) factory supplied, on a non-volatile memory area.
2nd step - Secondary bootloader, on flash memory area.
3rd step - Final Application, on flash memory area.

I’m using the ARM “fromelf” utility to translate the ELF image into suitable binary to be used later on with “mergebin” tool to combine different images into a single file to be loaded into flash memory.
Vector Table is being copied from application (flash memory area) into RAM region defined through a scatter file for steps 2 and 3 individually.

Assuming the flash burnt with the following contents:
Secondary bootloader.
Two final application copies “A” and “B” (via “mergebin” or secondary bootloader which capable of accepting a new image via UART and write it to flash)

and assuming the secondary bootloader knows “A” and “B” entry point addresses so it can branch to there – the problem is that “A” and “B” images created using the same scatter file thus both has the same load region base address.
So it does not matter which final application the secondary bootloader is branch to – the scatter loading stage of both will always start from the same flash absolute address which is wrong.

My question is how to avoid that? Maybe there is another approach to achieve my goal of being able to run the same application from different place?

Thanks,
Ronen

Author
Niv Peled
Posted
3-Oct-2017 12:29 GMT
Toolset
ARM
New! RE: Change load region at runtime

FYI: mergebin is something proprietary.
merge bin is a tool which combines bootloader and application and combines them into a single binary executable.
Gopala

Author
Tamir Michael
Posted
3-Oct-2017 17:01 GMT
Toolset
ARM
New! RE: Change load region at runtime

What is typically done is an update of the internal flash region that is dedicating to hosting the latest firmware. There is no reason to jump to 2 different locations; keep the alternate image aside, and program it upon need. In other words: you complicate the issue at hard tremendously.

Author
Westonsupermare Pier
Posted
3-Oct-2017 18:51 GMT
Toolset
ARM
New! RE: Change load region at runtime

I understood the question, I don't think you liked or understood the answer.

Use "Position Independent" code settings when generating your code output.

The Keil linker "freezes" a specific address into the binary object by fixing up and removing all relocation information.

If you want to "fix" the address being used at run time, or the time when you write into a specific memory address, then you're going to have to have access to the relocation information in the object file. And not from one where it has been completely stripped.

In the most simplistic sense have the linker build two copies of your binary, one at say 0x00444444, and a second at 0x00222222, and then DIFF the binaries and observe what and how much is different. Then look at how much additional information you'll need to "fix" that in your loader implementation.

Review "relocatable object file formats"

Author
Ronen Wino
Posted
8-Oct-2017 07:59 GMT
Toolset
ARM
New! RE: Change load region at runtime

Hi,

Sorry but not sure I understand the answer.

I’m trying to focus only at load region address during the load time of scatter loading stage.

The C library function of __scatterload carries out code and data copying/decompressing (unpackaged from the load region address) – my problem is how to set a “dynamic” load address to load the RAM areas.

To my best understanding this can’t be achieved because load address is hard-coded in map file.

Thanks,
Ronen

Author
Westonsupermare Pier
Posted
8-Oct-2017 20:47 GMT
Toolset
ARM
New! RE: Change load region at runtime

The .MAP simply reflects what the Linker has created.

What you need to do is
Get a better understanding of how processor executes code.
What causes address dependencies.
How Linkers and Loaders manage different tasks.
The difference between a binary file and an object file.

I suggested a very simple method to see how different things are, perhaps start by doing that and learning some basic things about the build process and tool functionality.

Author
Ronen Wino
Posted
9-Oct-2017 04:07 GMT
Toolset
ARM
New! RE: Change load region at runtime

With all due respect I suggest you try to soften your criticism and be more helpful.
Modest people are not preoccupied with themselves. Arrogant people have an inflated view of themselves.

Author
Colin Perth
Posted
9-Oct-2017 08:27 GMT
Toolset
ARM
New! RE: Change load region at runtime

You asked something and got the answer:

"The .MAP simply reflects what the Linker has created."

That is a perfectly correct answer and was followed by good suggestions of what you should study further.

I saw no criticism in what was written there.

Modest people are prepared to take advice. Arrogant people have an inflated view of themselves. I will ask you a rhetorical question: Which are you Ronen Wino ?

Author
Slava K
Posted
9-Oct-2017 09:23 GMT
Toolset
ARM
New! RE: Change load region at runtime

Hi All

The guy asked how to manipulate load regions, and he gets an answer - "go read and learn".
The whole idea of forum is to share information for your experience and help with ideas.
I believe Ronen did his "googling" and therefore posted here.

I am also interested in similar subject, and could not find solution in keil/arm documentation,
nor in other sources, so posting here to follow the discussion.

Can anybody share a link to PI example

Thanks,.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.