hello !! please i want to know how could i control the placement of RW data of a "xxxx.o" on a specific region into the flash PS : my input is a .axf file and my output would be a .hex file
Again, we don't know what your actual task is!
You seem to be fixated on this "partial linking" thing, but there's no evidence that it's a good or necessary approach.
This is why we keep asking you what the end goal is.
Again, please see: www.catb.org/.../smart-questions.html - you are focussing on the step, not the goal.
I think there are 2 possibilities:
1. You are over-complicating a standard task, which has a well-used, simple solution;
2. You really do have some special-case, complex requirement.
But we can't tell which unless you describe the end goal.
And we can't help you effectively without understanding the end goal.
The suspicion is strongly that it is case number 1.
My end goal is to implement section overlay for many modules . my current goal is how to reorganize RW section for that modules in specific adresses into internal flash for scheduling reason for the overlay manager . is it clear now ?
and why do you feel the need to do that?
Have you reviewed how others do it?
As Westonsupermare Pier said, it does seem that you need to spend a bit more time getting a firm grasp of the basics before moving on to advanced stuff like this.
Is this a school project?
ok thanks for your help
ARM Linker User Guide > Scatter-loading Features > Placement of sections with overlays
www.keil.com/.../armlink_pge1362066004071.htm
Ponder using a loader, so your code can load different modules. The ELF object format allows for a DLL type use case.
The format may be overly complicated for such a task, and a simpler more custom solution may be more workable.
in fact that's my goal , to implemant a dynamic loader but you didn't answer me sir how "they are accessible at an application level" ?
That means that your application code can "see" them - and, thus, use them.
Again, for a project like this, you really need to spend some significant time becoming properly familiar with the tools; eg,
The list of "Load$$..." execution region symbols is here: www.keil.com/.../armlink_pge1362065953229.htm
which points you to, among other things:
Methods of importing linker-defined symbols in C and C++
Methods of importing linker-defined symbols in ARM® assembly language
that's for coding in assembly or source mode but am just searching the address where a section or region is loaded into memory before the image containing it starts executing.
... but am just searching the address where a section or region is loaded into memory before the image containing it starts executing
Then YOU'd better start reading the documentation on the AXF/ELF format. They YOU can start writing your loader.
You're going in circles, from an "application level" you import symbols in the same way other functions and variables. It's not an "assembly" concept, its object file basics.
From the .AXF file
... i.__scatterload_zeroinit [Anonymous symbol #351] 0x20002588: 2000 . MOVS r0,#0 0x2000258a: e001 .. B 0x20002590 ; 0x20002590 0x2000258c: c101 .. STM r1!,{r0} 0x2000258e: 1f12 .. SUBS r2,r2,#4 0x20002590: 2a00 .* CMP r2,#0 0x20002592: d1fb .. BNE 0x2000258c ; 0x2000258c 0x20002594: 4770 pG BX lr 0x20002596: 0000 .. MOVS r0,r0 ... APBPrescTable 0x20002a84: 00000000 .... DCD 0 0x20002a88: 04030201 .... DCD 67305985 Region$$Table$$Base 0x20002a8c: 20002ac0 .*. DCD 536881856 0x20002a90: 20002ac0 .*. DCD 536881856 0x20002a94: 0000004c L... DCD 76 0x20002a98: 20002588 .%. DCD 536880520 Region$$Table$$Limit
... 354 puts 0x20002a11 Gb 1 Code Hi 0x1e 355 AHBPrescTable 0x20002a74 Gb 1 Data Hi 0x10 356 APBPrescTable 0x20002a84 Gb 1 Data Hi 0x8 357 Region$$Table$$Base 0x20002a8c Gb 1 -- Hi 358 Region$$Table$$Limit 0x20002a9c Gb 1 -- Hi 359 QPI_Mode 0x20002aa4 Gb 2 Data Hi 0x4
If you've stripped the symbols you'll have to go fish for the structures, or work with the objects earlier.
the first table how could i get it ? the second it's clear with fromelf command
the first table how could i get it ?
Looks like regular fromelf -c output. Check the manual.