The Blackfin series DSPs have built-in bootrom. After the corresponding Boot Mode is set, bootrom can play a role and read the user program to the specified position of the On-Chip cache or SDRAM, then the program starts from the preset address. In this way, user programs are required to be stored in a certain format, which is the LDR file format. The elfloader.exe tool was deployed in visual dspto convert dxe files to LDR files. Unfortunately, it does not provide a tool to convert LDR back to dxe. It only provides a link to an online sharing tool, which is ldrviewer, used to view the content of the LDR file. The reason is that the conversion from LDR to dxe is of little significance, because after conversion, all debugging information in the dxe file will be lost, and it is difficult to modify it after reverse conversion. Recently, I spent some time studying the conversion from LDR to dxe. I added the LDR viewing and conversion functions based on the original elfeditor and generated a new tool uctools. Several key issues are described as follows for your reference.
1 LDR File FormatThe vdsp documentation has clearly explained the LDR file format, but simply arrange some blocks in order, each block contains 10 bytes of block header and data of no more than 65535 bytes (multiple dxe are needed and several more control bytes are needed ). Specify the block size in the block header. The block is directed to the storage region and the two-byte flag, as shown below (Source: visualdsp ++ 4.5 loader and utilities manual revision 1.0, april 2006 ):
| Table 2-4. ADSP-BF531/bf532/BF533 block header Structure |
| Bit Field |
Description |
| Address |
4-byte address at which the block resides in memory. |
| Count |
4-byte number of bytes to boot. |
| Flag |
2-byte flag containing information about the block; the following text describes the flag structure. |
The significance of flag is as follows:
| Table 2-5. Flag Structure |
| Bit Field |
Description |
| Zero-fill Block |
Indicates that the block is for a buffer filled with zeros. the body of a zero block is not supported ded within the loader file. when the loader utility parses through. dxe file and encounters a large buffer with zeros, it creates a zero-fill block to reduce. LDR file size and boot time. if this bit is set, there is no block body in the block. |
| Ignore Block |
Indicates that the block is not to be booted into memory; skips the block and moves on to the next one. currently is not implemented for application code. |
| Initialization Block |
Indicates that the block is to be executed before booting. the initialization block indicator allows the on-chip Boot Rom to execute a number of instructions before booting the actual application code. when the on-chip Boot Rom detects an init block, it boots the block into internal memory and makes a call to it (initialization code must have an RTS at the end ). this option allows the user to run initialization code (such as SDRAM initialization) before the full boot sequence proceeds. initialization code can be encoded ded within. LDR file by using the-init switch. |
| Processor type |
Indicates the processor, either ADSP-BF531/bf532/bf538 or ADSP-BF533/bf534/bf536/bf537/bf539. after booting is complete, the on-chip Boot Rom jumps to 0xffa0 0000 for the ADSP-BF533/bf536/bf537/bf539 processor and to 0xffa0 8000 for the ADSP-BF531/bf532/bf538 processor. |
| Last Block |
Indicates that the block is the last block to be booted into memory. after the last block, the processor jumps to the start of L1 memory for application code execution. when it jumps to L1 memory for code execution, the processor is still in supervisor mode and in the lowest priority interrupt (ivg15 ). |
| Compressed Block |
Indicates that the block contains compressed data. The compressed block can include a number of blocks compressed together to form a single compressed block. |
Generally, the ignore flag of the first block of the LDR file should be 1, that is, it is not used, but other information can be set in this block.
2 dxe File FormatThe dxe file adds some vdsp-Specific Configurations Based on the ELF File Format, such as the e_type settings in the ELF File Header, some special debugging segments. Annotations,. attributs, and so on. However, only a few segments are required: Empty segments: This is the first segment in the ELF file, which does not contain any information, and the field header is set to 0. At least one segment for saving the string: this segment is usually the second segment, used to store strings such as segment names. Program segment: it is the program code. Each segment cannot exceed 65535 bytes .. Processor: this segment is not required. Visual DSP uses this segment to identify the DSP type targeted by the program. Its content is a string, such as "ADSP-BF531", "ADSP-BF561" and so on. Without this segment, visual DSP considers that the dxe program is developed for the set session. As for the program header, I always thought it was necessary. However, after testing, I found that the dxe file does not contain this part of information, and the vdsp still works!
3 Conversion from LDR to dxeFrom the comparison between the two files, we can easily see that the conversion method is to generate a corresponding program segment for each block in the LDR file that cannot be ignore, and set the corresponding section head. As for the content, of course, it is the original copy. Then, add an empty segment and a character segment, and set. processor.
