Hi,
I'm using Arm DS Version: 2022.2 as a trial version.
I've no arm chip yet thus i'm using Cortex-M55 FVP.
I'm trying to write kind of a boot rom sw that runs and load another 'hello world' application into code and data to different execution addresses in memory.
After boot rom ends with loading the code and data into memory it jumps into the 'hello world' Reset_Handler address and starts execution.
So far so good, the 'hello world' begin to run but I've noticed that the "__scatterload_copy" from arm c library is overwriting the RW data section with default pattern of 0xDFDFDFCF.
As a result a "SystemCoreClock" variable from "system_ARMCM55.c" initial value is being overwritten from "0x17D7840" into 0xDFDFDFCF and code based on this variable isn't working as expected..
I would be happy to understand how to avoid the "__scatterload_copy" operation in order not to overwrite the data the boot rom already loaded into data memory?
Thanks,Ronen
Hi Ronan,
That is right, the 'hello' code embedded into the bootrom image at 0x10000000. The 'hello' data is embedded into the bootrom image at 0x30000000.Currently it is embedded into the bootrom image only as a proof of concept - the bootrom takes these pieces of code+data and placed them into the memory according to the 'hello' image addresses set by its scatter file, In the future these pieces of code +data wil be fetched by hte boot rom from flash or arrived by some peripheral interfaces via host application to boot rom.My question is how can i avoid the "second set of init code"? i.e. i would like the arm c library to skip the startup code or to specifically skip the __scatterload_copy, is it possible?
>>"Does helloworld need to access SystemCoreClock or other such things?"Yes, the 'hello' prints a clock counts, so the SystemCoreClock is really needed.>>"do you expect helloworld to ever return?"No, the 'hello' should never returned.
I would try to " define the entry point as __main" and ping you for the result.Thanks,Ronen
Hi again Ronen,
There are two 'start up code sections to consider...
The system level code can be removed from your helloworld project by opening the .rteconfig file in the project, and deselecting Device > Startup. Also remove reference to this (ResetHandler) from the scatterloading file. The entry point should now be __main, at 0x10000000 (I see in your example you have hardcoded the entry point address of helloworld in your boot example.
To remove scatterloading, you could try to use the $Sub notation to patch in your own version of the __scatterload() function (which just returns):https://developer.arm.com/documentation/101754/0619/armlink-Reference/Accessing-and-Managing-Symbols-with-armlink/Use-of--Super---and--Sub---to-patch-symbol-definitions
But I believe you are going to hit runtime issues downstream... scatterloading also does things like set up RW Data... at a minimum, link with datacompressor off (or better, check that you have no RW data at all):https://developer.arm.com/documentation/101754/0619/armlink-Reference/armlink-Command-line-Options/--datacompressor-opt
Ronan
Hi Ronan,Thank you for your detailed response.
Will try the first approach once my DS Golden Edition is back to work (currently the FVP connection is broken due to some license issue in which you are trying to help as well :-)) .Will ping you right after,
Ronen
I just used "#if 0" for the entire "Reset_Handler" function instead of removing the Startup from .retconfig (i hope this is OK)
But eventually it didn't help.Regarding the entry point of the destination image ('helloworld') that should be "__main" as you have suggested - I thinks this won't work as the "__scatterload" of the C library still will be called. Pls see below snapshot from Arm Application Note 241:I tried that and it appears that the "__scatterload" is the actual entry point of the application, pls see below snapshot of the debugger:
my boot rom code target address to jump into is : #define IMG_ENTRY_POINT_ADDRESS (0x100007c1)
So all in all it seems i can't avoid the __scatterload call.
Hi Ronen,
The entry point is __main, who's first instruction is a call to __scatterload.
If you implement (something like):
void $Sub$$__scatterload { return; }
The linker should point that function call to your implementation.
I got your point, thanks.
I've tried that and really the scatter load does nothing as expected. However the hello world isn't working as expected (SystemCoreClock isn't initialized to its default data value - this is also understood - we skipped the scatter load).
Feels like a ctach-22.
Ronan, sorry but maybe I'm missing something here, I will try again:How a typical boot rom application (that gets its destination fw binary data+code through external host, flash memory etc) can branch (and not returned) to its fw application and continue running from there?My understanding is that the boot rom accepts the fw code+data, copy it into a different memory locations (according to the fw scatter file definition and sizes) and branch into the fw application entry point,.
Thanks for your great support.Finally it worked for me.
The turning point was your last suggestion to skip the scatter load functionality from the hello world app itself.Rather than that i had two other bugs:1. I was branching into the vector section instead to the Reset_Handler (i.e. my Image Entry point was wrong).2. The hello world Code section (as an array in the boot rom) was wrong (different than the code we saw in disassembly). That happened due to a wrong path.