About input section in DSP memory allocation

Hi Da,

Whether a block of memory is RAM or ROM is specified in the MEMORY{...} section of the LDF (which precedes the SECTIONS{...} block). Each memory range specified within this block can be assigned a type; TYPE RAM or TYPE ROM.

Any objects mapped to a ROM section by an INPUT_SECTIONS command will be 'tagged' as such in the .DXE file produced by the Linker.

A typical use case is that functions/data mapped to ROM are intended to be written to Flash, or similar non-volatile memory, but when loading a .DXE file the Emulator does not do this; it simply skips the ROM sections, and only loads RAM sections to the target. In order to get these ROM sections into non-volatile memory you need to enable the use of the Splitter, which extracts ROM sections from the DXE to produce a loader stream (where the Elfloader does the opposite: it extracts RAM sections to create the loader boot stream).

The resultant ROM loader stream can then be programmed to Flash.

Let me know if you need any more information, or have any additional questions.

regards,

Craig.

Hi,

This is only the input section.

But what is output section?and where to store output section?

If they are both stored in memory,that is a waste of memory space.

-da

Sent from my iPod

On 2010-4-26, at 1:05, CraigG <analog@sgaur.hosted.jivesoftware.com

Hello again,

Each of the commands in the SECTIONS{...} block of the LDF consist of multiple parts, as follows:

output_section_name

{

section_commands

//e.g.:

INPUT_SECTIONS($OBJECTS(input_section_name))

} > memory_segment

The output_section_name serves as a reference for the linker to produce a grouping of objects containing code/data marked with input_section_name that are to be mapped to a memory_segment.

As with all the relevant section names, these serve as instructions to the linker as to how to construct the DXE executable file from the provided objects, and provide guidance on where in memory to try and place all these objects. Output Section information does make it into the final DXE, however much like Debug Information none of this information is stored in memory on the target when the DXE is loaded; the emulator extracts the code and data bytes from the DXE and writes them to the appropriate locations in memory on the target.

So, no memory is wasted by the input/output section information.

regards,

Craig.

Hey thanks for the info you've shared. It does help me a lot knowing this. And as for my research paper help, it goes as well to.

Thank you so much.

I think I understand now. From what you have said, I think the content of the output section has nothing to do with the "function" of the assembly code.

On one hand, It deals with how to map an executable image to the memory, on the other hand, the executable image is also linked due to output section instructions. At the same time, the executable image consists of several input sections from several objects. And the objects are from the assembler.

-da

Hello again,

I have another question, what is the .DXE file please?

I read from those dsp user manuels,the executable file format should be COFF, right?

So, I am thinking that the .o files are linked into COFF directly and then loaded into memory,

But what is the DXE file?

Thank you for your answer.

-da

Hi,

the SHARC tools used to produce output files in COFF format, however this was some time ago back in the 3.3 Tools. As of VisualDSP 4.0 (not to be confused with the more recent VisualDSP++ tools), back in '98, the output files have been in ELF format.

So the COFF executable ".exe" file, is a legacy file type. The DXE refers to the ELF (with DWARF-2 debugging information) format executable ".dxe" file that the newer tools produce.

Hope that explains it, if you have any other questions let me know.

regards,

Craig

You're welcome. The file types themselves, and support thereof, comes down to the VisualDSP++ tools. The latest tools actually only support the ELF format files. When a DXE is loaded, all of the formatting, debug information, etc, is stripped out and the Emulator only loads the actual bytes of machine code to the appropriate memory locations (based on the ELF information) on the target.

Similarly, with the COFF files the same thing would happen, only this time it's all the COFF formatting information, debug information, etc that is being stripped out.

So, the processor isn't actually executing different file types; it's just executing the bytes of machine code copied to it by the Emulator.

As I mentioned, the latest tools don't support the COFF format; you can only load ELF format DXEs. We actually provide a handy utility, in case you have older COFF files, which can convert from COFF to ELF so that you can load them. This utility is called coff2elf.exe (there is a counter-part elf2coff.exe also), and is located in the VisualDSP++ installation directory.

There's a (pretty old) Application Note, "EE-110 A Quick Primer on ELF and DWARF", which may be of interest to you. This is available via 'SHARC Processors Technical Library:Application Notes" at the link below:

http://www.analog.com/ee-notes

If you need to contact us at support at all, you can do so through the following link:

http://www.analog.com/processors/support

Good luck with the PHD.

Craig.

Hi dude,

Your reply is awesome. The DXE file turns out to be ELF file, then I can understand.

I read from papers that ELF is for LINUX and COFF is for windows, without noticing that ELF is basically the DXE.

So you mean that DSP can execute both COFF and ELF? As DSP do not have OS on it, how can the DSP chip deal with them?

Is there any manuel for such stuff?

Thank you.

-da

Hi Da,

Unfortunately I'm not familiar with the TI tools. My comments above are simply that our tools moved away from COFF files to ELF a long time ago. The output file format from the tools is not important to the processor at all; as long as the tools can extract the appropriate data to be downloaded to the target processor, that's all that matters.

Our tools used to deal with COFF and therefore could extract the appropriate data to download to the target processor. Now we deal with ELF, which has the same data, but in a different format. Our tools now extract that data from the ELF file to download to the target.

You would have to contact TI's support, or reference their documentation for details of what file formats they use.

regards,

Craig.

Hello again,

You said no more DSP execute COFF ?

Are all companys same? Like ADI and TI? Or you were only talking about ADI?

Now I am using a DSP from TI. For the output file, which I think is the executable file, when I check the property.

Type of the file is OUT.

Does OUT belong to COFF or ELF? I've never seen .exe or .dxe.

regards,

-da