How to control the order of tags in the ldr file

Hi,

There are a couple of options. The first is to use the Linker to control the placement of the data at build time, so that it is consistent. This can be done, for example, by using the RESOLVE() command in the LDF to resolve your structure to a specific address. Similarly, you could use the #pragma section() directive to set the input section name for your structure to a custom name. Then, in the LDF you would add an INPUT_SECTIONS(...) command to place this custom input section. For example:

struct myStruct (...);

#pragma section("VersionInfo")

struct myStruct structInstance;

Then in the LDF, in an appropriate location add the following to map the data to a specific part of memory:

INPUT_SECTIONS($OBJECTS(VersionInfo))

You could either add this to an existing output section command, or create your own like:

VersionInfo_output_section

{

INPUT_SECTIONS($OBJECTS(VersionInfo))

} > MEM_L1_CODE

If you use Blackfin, and have a system builder LDF, you should ensure that you do not make any changes outside of the generated $VDSG sections.

An alternative would be to edit the LDR file directly. The FIRST block is typically an IGNORE block, meaning its payload is ignored during boot. This means you could edit the first block, add the version information into the payload of the first block, and read it from this known location.

Any changes you make, you would need to fix the checksum in the LDR file to make sure it is correct, as otherwise these changes would make the boot fail.

Regards,

Craig

Thanks Craig,

May be you could comment on the following. (BTW, I am using SHARC 21364). I actually tried your first suggestion earlier and I could see that my structure would indeed show at the correct location in the map, however, it did not seem to change the location of my "key" string in the ASCII ldr file. My understanding is that the ldr file contains few self-contained sections with the header of each section containing information about the section address, length and so on. So, sounds like directing the linker to place the section at a preferred location in the map does not mean that the loader utility could not move the "image" of that section in the ldr file somewhere else, in my case toward the end of the ldr file.

If the above is true, then sounds like your second method to post-process the ldr file to place the version in the IGNORE block and change the checksum is the only alternative. Could you recommend any documentation with details on the ASCII ldr file? I found a section on the ASCII format in the loader utility manual, but I don't think it goes to that level of details.

Thanks again,

IGNORE blocks are used in Blackfin ldr streams.

Here is some information for the SHARC elfloader targetting the ADSP-213xx.

First suggestion is to build with verbose output on the elfloader step so you can see the ordering of the sections as it creates the ldr boot stream.

What boot mode is used?

For SPI boot, the elfloader will re-order the 40 and 48-bit segments from the DXE file sequentially by address.

Some general information:

A multi processor SHARC ldr stream contains the code from the kernel (code section seg_ldr) followed by the 1st DXE multi-proc block header, 1st DXE data blocks, then 2nd dxe multi-proc block header, 2nd dxe data block and so on.

If the ldr build has the -NoKernel switch, then the kernel code is omitted from the ldr file.

The multi processor format of the ldr stream is when the build of the multi processor application ldr stream is in one elfloader call using -id#exe=foo.dxe switches.

Some references in the Loader and Utilities Doc in VisualDSP++:

ADSP-2136x/2137x/2146x/2147x/2148x Multi-Application (Multi-DXE) Management

Figure 6-4. Multiprocessor Boot Stream

Since your posting mentioned multiple ldr files it sounds as if each DXE is being built into its own ldr boot stream with separate elfloader build steps.

In that case, there will be no multi-proc block headers but the same overall structure of the ldr stream applies.

Each header for a data block consists of three 32-bit words: the block tag, word count, and destination address.

Loader and Utilities Doc

Table 6-14 details the ADSP-2126x/2136x/2137x/2146x/2147x/2148x processor block tags.

The following EE-note also has information on the ldr stream including the various block header tags for the different SHARC processors:

EE-56: Tips and Tricks on SHARC EPROM and Host Boot Loader

I'm not so sure that you need to get into quite that level of detail though.

If there is something specific to your application that you have further questions on, contact Processor Tools Support with more detailed information on the build steps and DXE files and we can follow-up there.

Thank you BarbaraZ, I think this answers my question.

So, my present understanding is that in my case (SHARC-21364, SPI boot mode, no multi-proc headers) my only option is:

1. First, use #pragma section in the source file where my revision structure is defined

2. Second, modify the ldr file to place that section into a 48-bit segment. This is because the loader ALWAYS puts 48-bit segments in the ldr stream in front of the 32-bit segments, meaning that my if left in a 32-bit segment the revision structure will end up towards the end of the ldr stream

3. Third, change the ldf file to map that 48-bit segment containing the revision structure in-front of my code as per BarbaraZ "the elfloader will re-order the 40 and 48-bit segments from the DXE file sequentially by address"

4. Lastly, my function that searches through the flash looking for the revision info needs to account for the fact that my data would be 48-bit wide now.

Thanks again