Home » Archived » DSDP - Real-Time Software Components (RTSC) » accessing runSegment/loadSegment addresses in an assembly file(Boot copy from FLASH using RTSC w/ DSP/BIOS 6 on a TMS320F28335)
|
| Re: accessing runSegment/loadSegment addresses in an assembly file [message #540362 is a reply to message #540098] |
Tue, 15 June 2010 19:29   |
 Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070301020702080906030003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mark,
Unfortunately there isn't a one line solution for defining start and
size symbols from your configuration script. The TI linker recently
added this nice capability, but the configuration model does not (yet)
have a way to leverage it simply.
However, it is possible to define these symbols for your application.
In the spirit of "make the simple things simple and complex things
possible", RTSC provides an "escape hatch" that allows you to
_completely_ control the generated linker command files. While this is
a heavy-handed solution (described below), it does allow you to leverage
every feature of the underlying tools.
If you're thinking that defining these symbols is a "simple thing" that
should be _simple_, I agree and I'll file a bug to track this issue.
dave
Escape hatch solution
---------------------
All generated linker command files are generated from a "template". A
template is an arbitrary text file that's read line-by-line and lines
without special characters are output without change. Lines with
special characters are interpreted as XDCscript expressions which are
evaluated and their value is output. See
http://rtsc.eclipse.org/docs-tip/XDCscript_-_Template-Body.
Finally, configuration scripts can specify the template to use to
generate the linker command file. See
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/cfg/Program. html#link.Template
So, rather than specifying the section information via
Program.sectMap, you can specify it directly in the template used to
generate the linker command file.
There are several different ways of managing linker templates:
1. you can copy the generated linker command file to your project,
edit it to suit you application, and specify this file as the
linker template (via Program.linkTemplate = ...);
2. you can copy the template used to generate you app's linker
command file to your project, edit it, and specify this file
as the linker template; or
3. you can create a template that expands the normal template,
and adds/removes/changes only the lines required.
The first two require constant updates as you make changes to you
application or as new versions of ti.targets become available. So,
while they are the easiest to understand, they are the hardest to
maintain. The last option requires little or no changes during
development and is relatively easy for the expert to create. So, I'll
outline the template for option 3 below and attach a complete template
that you should be able to use (with minor edits).
The template below, linkcmd.xdt, generates the original linker command
file to a tmp file named "orig.xdl", opens this file, and replaces the
just ".text" section placement line with the following lines:
.text:load > SDRAM START(_text_load) SIZE(_text_size)
.text:run > IRAM START(_text_run)
This template defines a function, named filter, which simply takes an
input line and, if it's the line that places the ".text" section,
replaces it with the lines above. Since this function is a JavaScript
function with full regular expression facilities it can be modified to
handle very complex application requirements.
linkcmd.xdt:
%%{
/* generate original command file from template into orig.xdl */
var tfile = this.platform.getLinkTemplate(this);
var template = xdc.loadTemplate(tfile);
template.genFile("orig.xdl", this, $args);
/* function used to filter original linker command file */
function filter(line) {
if (line.match(/\s*\.text:.*>/)) {
line = ".text:load > FLASH START(_text_load) SIZE(_text_size)\n";
line += ".text:run > SRAM START(_text_run)\n";
return (line);
}
return (line);
}
%%}
%/* read and "patch" generated linker command file to add symbols */
%var line;
%var file = new java.io.BufferedReader(java.io.FileReader("orig.xdl"));
%while ((line = file.readLine()) != null) {
`filter(String(line))`
%}
%file.close();
On 6/14/2010 2:37 PM, Mark Takatz wrote:
> I have an RTSC project and I need to copy several sections from FLASH to
> RAM during the boot process. Using TI's standard linker command file, it
> is fairly straight-forward to use the LOAD_START(_load_start),
> RUN_START(_run_start), and SIZE(_size) macros to assign addresses to
> these symbols, then pick them up in the codestart assembly file using
> .global _load_start, _run_start, _size at which point I can then copy
> each section as required.
>
> However, it is not as apparent how I would do this with an RTSC
> configuration script. I have defined my sections as:
>
> var Section = new Program.SectionSpec;
> Section.runSegment = "SRAM";
> Section.loadSegment = "FLASH";
> Program.sectMap[".text"] = Section;
>
> Is there an equivalent way to get the addresses set in the configuration
> script mapped to the assembly globals? There is one help topic regarding
> this at TI's website and they refer the poster here though it seems said
> poster did not follow through and there have been no further replies
> since December '09.
>
> Thanks in advance,
>
> Mark Takatz
--------------070301020702080906030003
Content-Type: text/plain;
name="flash.xdt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="flash.xdt"
JS8qCiUgKiA9PT09PT09PSBsaW5rY21kNC54ZHQgPT09PT09PT0KJSAqICBU aGlzIGlzIHRl
bXBsYXRlIGZpbGUgaWxsdXN0cmF0ZXMgaG93IG9uZSBjYW4gZmlsdGVyIHRo ZSBsaW5rZXIg
Y29tbWFuZAolICogIGZpbGUgdGhhdCBpcyBub3JtYWxseSBnZW5lcmF0ZWQg ZnJvbSB0aGUg
dGVtcGxhdGUgc3VwcGxpZWQgYnkgdGhlCiUgKiAgZXhlY3V0YWJsZSdzIHBs YXRmb3JtLiAg
VGhpcyBhbGxvd3Mgb25lIHRvIHVwZGF0ZSB0aGUgcGxhdGZvcm0gd2l0aG91 dAolICogIGhh
dmluZyB0byB1cGRhdGUgdGhpcyBmaWxlLgolICoKJSAqICBUaGlzIHRlbXBs YXRlIGlzIGV4
cGFuZGVkIGFmdGVyIHRoZSBjb25maWd1cmF0aW9uIHNjcmlwdCBydW5zIGFu ZCB0aGUKJSAq
ICByZXN1bHRzIHBsYWNlZCBpbiBhIGZpbGUgKHdpdGggZXh0ZW5zaW9uIC54 ZGwpIGFzc29j
aWF0ZWQgd2l0aCB0aGUKJSAqICBleGVjdXRhYmxlLgolICoKJSAqICBMaW5r ZXIgdGVtcGxh
dGVzIGFyZSBwYXNzZWQgdGhlIGZvbGxvd2luZyBhcmd1bWVudHM6CiUgKiAg ICAgJG91dAkg
ICAgLSBhbiBvcGVuIGZpbGUgc3RyZWFtIGZvciB0aGUgZ2VuZXJhdGVkIGxp bmtlcgolICoJ
CSAgICAgIGNvbW1hbmQgZmlsZQolICoJJGFyZ3MJICAgIC0gYW4gYXJyYXkg b2YgemVybyBv
ciBtb3JlIGxpYnJhcmllcyB0aGF0IHNob3VsZCBiZSBsaW5rZWQKJSAqCQkg ICAgICB3aXRo
IChpbiB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4gdGhlIGFyZ3VtZW50IGxp c3QpCiUgKgol
ICogIFRoZXNlIGFyZ3VtZW50cyBhcmUgYXZhaWxhYmxlIHZpYSB0aGUgc3Rh bmRhcmQgSmF2
YXNjcmlwdCBhcmd1bWVudHMKJSAqICBhcnJheTsgdGhlIGZpcnN0IGFyZ3Vt ZW50IGNhbiBh
bHNvIGJlIGFjY2Vzc2VkIHZpYSB0aGUgbmFtZSAiJG91dCIuCiUgKiAgSW4g YWRkaXRpb24g
dG8gdGhlc2UgYXJndW1lbnRzLCB0aGVyZSBpcyBhIGdsb2JhbCB2YXJpYWJs ZSBuYW1lZAol
ICogICd0aGlzJyB0aGF0IGlzIHNldCBhcyBmb2xsb3dzOgolICoJdGhpcwkg ICAgLSB0aGUg
cHJvZ3JhbSBvYmplY3QKJSAqLwolJXsKICAgIC8qIGdlbmVyYXRlIG9yaWdp bmFsIGNvbW1h
bmQgZmlsZSBmcm9tIHRlbXBsYXRlIGludG8gb3JpZy54ZGwgKi8KICAgIHZh ciB0ZmlsZSA9
IHRoaXMucGxhdGZvcm0uZ2V0TGlua1RlbXBsYXRlKHRoaXMpOwogICAgdmFy IHRlbXBsYXRl
ID0geGRjLmxvYWRUZW1wbGF0ZSh0ZmlsZSk7CiAgICB0ZW1wbGF0ZS5nZW5G aWxlKCJvcmln
LnhkbCIsIHRoaXMsICRhcmdzKTsKCiAgICAvKiBmdW5jdGlvbiB1c2VkIHRv IGZpbHRlciBv
cmlnaW5hbCBsaW5rZXIgY29tbWFuZCBmaWxlICovCiAgICBmdW5jdGlvbiBm aWx0ZXIobGlu
ZSkgewogICAgICAgIGlmIChsaW5lLm1hdGNoKC9ccypcLnRleHQ6Lio+Lykp IHsKICAgICAg
ICAgICAgcHJpbnQoIm9yaWdpbmFsIGxpbmU6ICIgKyBsaW5lKTsKICAgICAg ICAgICAgbGlu
ZSA9ICAiLnRleHQ6IGxvYWQgPiBGTEFTSCBTVEFSVChfdGV4dF9sb2FkKSBT SVpFKF90ZXh0
X3NpemUpXG4iOwogICAgICAgICAgICBsaW5lICs9ICIudGV4dDogcnVuICA+ IFNSQU0gIFNU
QVJUKF90ZXh0X3J1bilcbiI7CiAgICAgICAgICAgIHByaW50KCJuZXcgICAg ICBsaW5lOiAi
ICsgbGluZSk7CiAgICAgICAgICAgIHJldHVybiAobGluZSk7CiAgICAgICAg fQogICAgICAg
IHJldHVybiAobGluZSk7CiAgICB9CiUlfQolLyogZmlsdGVyIG9yaWdpbmFs IGxpbmtlciBj
b21tYW5kIGZpbGUgdG8gYWRkIHN5bWJvbHMgKi8KJXZhciBsaW5lOwoldmFy IGZpbGUgPSBu
ZXcgamF2YS5pby5CdWZmZXJlZFJlYWRlcihqYXZhLmlvLkZpbGVSZWFkZXIo Im9yaWcueGRs
IikpOwold2hpbGUgKChsaW5lID0gZmlsZS5yZWFkTGluZSgpKSAhPSBudWxs KSB7CmBmaWx0
ZXIoU3RyaW5nKGxpbmUpKWAKJX0KJWZpbGUuY2xvc2UoKTsK
--------------070301020702080906030003--
|
|
| | |
| Re: accessing runSegment/loadSegment addresses in an assembly file [message #540933 is a reply to message #540098] |
Thu, 17 June 2010 16:26 |
Mark Takatz
Messages: 5
Registered: June 2010 |
Junior Member |
|
|
After some tinkering to get everything just right, I finally have a working copy from FLASH routine using RTSC with DSP/BIOS 6. The linker command "extender" needs to be modified if you plan to move more than one block to the same memory segment, however.
As an example, modify the expansion to something like this:
if (line.match(/\s*\.const.*>/)) {
print("original line: " + line);
line = " .const: LOAD = FLASH, PAGE 0, RUN = RAM, PAGE 0, ";
line += "LOAD_START(__c_load_start), RUN_START(__c_run_start),
SIZE(__const_size)\n";
print("new line: " + line);
return (line);
}
Using the START keyword assigns the memory segment address to each of the keywords, so anything that is targeted to the same segment will overlap, e.g., copying .pinit and .cinit from FLASH to SRAM, will result in the same run from location in SRAM. LOAD_START and RUN_START properly assign the desired locations.
As a result of this, the map file will have lines that look like this:
.const 1 00338100 0000128a RUN ADDR = 00204000
rather than to separate .const sections (one for the load and one for the run at the beginning of the memory segment). This should be familiar to those that have done this the old way using custom linker command files.
One oddity I noted was that I was unable to create my own sections if they did not have a . in front of them, e.g., I have a section .fastFuncs that works well with this approach, but if I remove the . from it the expansion does not pick it up properly. At the moment, I don't care... I'm booting from FLASH and running from RAM now. 
Mark
|
|
|
| Re: accessing runSegment/loadSegment addresses in an assembly file [message #541004 is a reply to message #540933] |
Fri, 18 June 2010 01:00 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Mark,
Thanks for following up on this.
You're right, we should probably always use LOAD_START and RUN_START in
lieu of just START. I originally tested these macros on the c6x
architecture and discovered several limitations which lead me to simply
create two separate lines per output section, one for run placement and
one for load placement. In fact, I was never able to get good values in
the defined symbols when using the '>' operator unless I used separate
lines.
Bottom line: It's always good check the values of these symbols after
the link - either in the liner .map file or via the nm* tool.
dave
On 6/17/2010 9:26 AM, Mark Takatz wrote:
> After some tinkering to get everything just right, I finally have a
> working copy from FLASH routine using RTSC with DSP/BIOS 6. The linker
> command "extender" needs to be modified if you plan to move more than
> one block to the same memory segment, however.
>
> As an example, modify the expansion to something like this:
>
> if (line.match(/\s*\.const.*>/)) {
> print("original line: " + line);
> line = " .const: LOAD = FLASH, PAGE 0, RUN = RAM, PAGE 0, ";
> line += "LOAD_START(__c_load_start), RUN_START(__c_run_start),
> SIZE(__const_size)\n";
> print("new line: " + line);
> return (line);
> }
>
> Using the START keyword assigns the memory segment address to each of
> the keywords, so anything that is targeted to the same segment will
> overlap, e.g., copying .pinit and .cinit from FLASH to SRAM, will result
> in the same run from location in SRAM. LOAD_START and RUN_START properly
> assign the desired locations.
>
> As a result of this, the map file will have lines that look like this:
>
> const 1 00338100 0000128a RUN ADDR = 00204000
>
> rather than to separate .const sections (one for the load and one for
> the run at the beginning of the memory segment). This should be familiar
> to those that have done this the old way using custom linker command files.
>
> One oddity I noted was that I was unable to create my own sections if
> they did not have a . in front of them, e.g., I have a section
> .fastFuncs that works well with this approach, but if I remove the .
> from it the expansion does not pick it up properly. At the moment, I
> don't care... I'm booting from FLASH and running from RAM now. :)
>
> Mark
|
|
| | |
| Re: accessing runSegment/loadSegment addresses in an assembly file [message #554540 is a reply to message #554422] |
Mon, 23 August 2010 13:56 |
Mark Takatz
Messages: 5
Registered: June 2010 |
Junior Member |
|
|
Here's what mine looks like now (sorry for the formatting, but I can't get it to accept leading spaces or tabs):
%/*
% * ======== linkcmd4.xdt ========
% * This is template file illustrates how one can filter the linker command
% * file that is normally generated from the template supplied by the
% * executable's platform. This allows one to update the platform without
% * having to update this file.
% *
% * This template is expanded after the configuration script runs and the
% * results placed in a file (with extension .xdl) associated with the
% * executable.
% *
% * Linker templates are passed the following arguments:
% * $out - an open file stream for the generated linker
% * command file
% * $args - an array of zero or more libraries that should be linked
% * with (in the order they appear in the argument list)
% *
% * These arguments are available via the standard Javascript arguments
% * array; the first argument can also be accessed via the name "$out".
% * In addition to these arguments, there is a global variable named
% * 'this' that is set as follows:
% * this - the program object
% */
%%{
/* generate original command file from template into orig.xdl */
var tfile = this.platform.getLinkTemplate(this);
var template = xdc.loadTemplate(tfile);
template.genFile("orig.xdl", this, $args);
/* function used to filter original linker command file */
function filter(line) {
if (line.match(/\s*\.fastFuncs:.*>/)) {
print("original line: " + line);
line = " .fastFuncs: LOAD = FLASHEH, PAGE 0, RUN = L23SARAM, PAGE 0, ";
line += "LOAD_START(__F_LoadStart), RUN_START(__FastRunStart), SIZE(__FastSize)\n";
print("new line: " + line);
return (line);
} else if (line.match(/\s*\.econst:.*>/)) {
print("original line: " + line);
line = " .econst: LOAD = FLASHA, PAGE 1, RUN = DSRAM, PAGE 1, ";
line += "LOAD_START(__Ec_LoadStart), RUN_START(__EconstRunStart), SIZE(__EconstSize)\n";
print("new line: " + line);
return (line);
} else if (line.match(/\s*\.const:.*>/)) {
print("original line: " + line);
line = " .const: LOAD = FLASHA, PAGE 1, RUN = DSRAM, PAGE 1, ";
line += "LOAD_START(__C_LoadStart) RUN_START(__ConstRunStart), SIZE(__ConstSize)\n";
print("new line: " + line);
return (line);
} else if (line.match(/\s*\.switch:.*>/)) {
print("original line: " + line);
line = " .switch: LOAD = FLASHEH, PAGE 0, RUN = MSARAM, PAGE 1, ";
line += "LOAD_START(__Sw_LoadStart), RUN_START(__SwitchRunStart), SIZE(__SwitchSize)\n";
print("new line: " + line);
return (line);
} else if (line.match(/\s*\.vecs:.*>/)) {
print("original line: " + line);
line = " .vecs: LOAD = FLASHA, PAGE 1, RUN = PIEVECT, PAGE 1, ";
line += "LOAD_START(__V_LoadStart),RUN_START(__VecsRunStart), SIZE(__VecsSize)\n";
print("new line: " + line);
return (line);
} else if (line.match(/\s*\.reset:.*>/)) {
print("original line: " + line);
line = " .reset: load >> RESET, PAGE 0, type = DSECT";
print("new line: " + line);
return (line);
}
return (line);
}
%%}
%/* filter original linker command file to add symbols */
%var line;
%var file = new java.io.BufferedReader(java.io.FileReader("orig.xdl"));
%while ((line = file.readLine()) != null) {
`filter(String(line))`
%}
%file.close();
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:49:21 GMT 2024
Powered by FUDForum. Page generated in 0.03199 seconds |
] 
Search
Help
Register
Login
Home
