- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
I am struggling with the boot-load code of a custom target. Here is the first level bootload assembly code, after being processed by the hex6x (binary option, -b) and the absolute lister, abs6x:
5 * First-level boot-loader, boot_1.asm
6 * This is patterned after a RESET IST entry, as all
7 * it does is branch to the 2nd-level bootloader, boot_2
8 *------------------------------------------------------------------------------
9 * Global symbols
10 .global _boot_1
11
12 *------------------------------------------------------------------------------
13 * Global symbols referenced in this file, defined elsewhere
14 .ref _boot_2
15
16 *------------------------------------------------------------------------------
17 00000000 .sect ".text:boot_1"
18 .align 32
19
20 00000000 _boot1:
21 00000000 003C30F6 STW B0,*--B15
22 00000004 0000002A! MVKL _boot_2,B0
23 00000008 0000006A! MVKH _boot_2,B0
24 0000000c 00000362 B B0
25 00000010 003C36E6 LDW *B15++,B0
26 00000014 00002000 NOP 2
27 00000018 00000000 NOP
28 0000001c 00000000 NOP
29 *------------------------------------------------------------------------------
No Assembly Errors, No Assembly Warnings
Here are the first few lines of the boot_2 assembly code, also after being assembled, linked (coff), hex6x with -b (binary) option, and run through abs6x:
A 23 .asg A15, FP
A 24 .asg B14, DP
A 25 .asg B15, SP
A 26 .global $bss
A 27
A 28 ; .file "N:\h2o\src\Projects\DSP\SPAM_5G\boot_5g.asm"
A 29
A 30 90000400 .sect ".text:boot_2"
A 31 ; .clink ; don't use this !! It kills link of un-referenced code !!!
A 32 .global _boot_2
A 33 .ref _c_int00
A 34 ; .sym _boot_2,_boot_2, 32, 2, 0
A 35 ; .func 24
A 36 ;----------------------------------------------------------------------
A 37 ; 24 | void boot_2(void)
A 38 ;----------------------------------------------------------------------
A 39
A 40 ;******************************************************************************
A 41 ;* FUNCTION NAME: boot_5g *
A 42 ;* *
A 43 ;* Regs Used : A
A 44 ;* B
A 45 ;* Local Frame Size :
A 46 ;******************************************************************************
A 47 90000400 _boot_2:
A 48 ;** --------------------------------------------------------------------------*
A 49 ; .sym _i,4, 4, 1, 32
A 50 ; .sym _wt,$C$L1, 0, 6
A 51
A 52 ;; spin loop so the debugger/emulator can attach
A 53 90000400 008008C2 zero B1
A 54 90000404 50000092 _spin: [!B1] B _spin
A 55 90000408 00008000 nop 5
A 56 9000040c 00000000 _spin_end: nop
A 57
A 58 ; 27 | // Initialize FPGA registers.
A 59 ;----------------------------------------------------------------------
A 60 ; 28 | *(int *)0xA0040020 = 0x0; // *START_MEAS = 0x0; // stop the measurement
A 61 ;----------------------------------------------------------------------
A 62 90000410 0280102A MVKL .S2 0xa0040020,B5
A 63 90000414 02D0026B MVKH .S2 0xa0040020,B5
A 64 90000418 020000FA || ZERO .L2 B4 ; |28|
A 65 9000041c 021402F6 STW .D2T2 B4,*B5 ; |28|
A 66 90000420 00002000 NOP 2
All sources were compiled/assembled with the following compiler/assemble options and map file, from my Rational OMAKE file. Note that I suspected the near-far option might have been the culprit, so set the "far" memory model, but it did not result in a "correct" absolute address for the branch to _boot_2:
DBG_REL = --symdebug:coff -d"_RELEASE"
CFLAGS = $(DBG_REL) -k -ss -px \
-pdf -pdsw225 -al \
-pdv -pden -mv6710 \
--mem_model:data=far \
-fr$(OBJ_DIR) \
-fs$(ASM_DIR) \
-ft$(TMP_DIR) \
-fb$(ABS_DIR) \
-ff$(LST_DIR) \
-d$(SPAM_TYPE) \
-i$(PROJ_DIR) -i$(DSP_COMMON_DIR) \
-i$(TMP_DIR) -i$(OBJ_DIR) \
-i$(INCLUDE) -i$(INCLUDE)\include
Linker flags/options:
LNKFLAGS = -z -a -c -w -x \
--rom_model -stack 0x400 \
-i$(TI_DIR)\lib -i $(INCLUDE)\csl\include \
-i$(TI_DIR)\include \
-i$(ASM_DIR) -i$(OBJ_DIR) \
-m$(MAP_FILE) -l$(LNK_LIBS)
Linker command file:
MEMORY
{ /* 6713 Memory notes */
BOOT1: origin = 0x000000 len = 0x400 /* level 1 boot code (branch) */
INT_VEC: origin = 0x00000400, len = 0x400 /* relocated interrupt table */
L2_RAM: origin = 0x000800 len = 0x2F800 /* fast on-chip SRAM, 195k */
L2_4WAY: origin = 0x030000 len = 0x10000 /* 4-way cache, 64k -- STAY OUT */
CE1_BOOT1: origin = 0x90000000 len = 0x400 /* level 1 boot, remapped to 0x0 */
CE1_BOOT2: origin = 0x90000400 len = 0x400 /* level 2 boot, shared mem */
CE1_IVT: origin = 0x90000800 len = 0x400 /* interrupt table, shared mem */
CE1_SRAM: origin = 0x90000C00, len = 0x3F400 /* slow external SRAM, 259.1k */
}
SECTIONS
{
.text:boot_1: load=CE1_BOOT1, run = BOOT1
.text:boot_2: >CE1_BOOT2 /* emu will not execute this code*/
.text:IVT: > CE1_IVT /* slower, but no copy required */
.text: > CE1_SRAM /* pgm code NOT boot-loader */
.const: > CE1_SRAM /* constants */
.cinit: > CE1_SRAM /* global c-runtime init */
.data: > CE1_SRAM
.stack: > L2_RAM
.bss: > L2_RAM
.far: > L2_RAM /* 6713 compiler artifact */
.cio: > L2_RAM /* 6713 compiler artifact */
.ppdata: > CE1_SRAM /* 6713 compiler artifact */
My questions:
1. What is the meaning of the exclamation point following the opcodes 0000002a, and 0000006a ??
2. The absolute listing shows that boot_2 is located at 0x900000400, so I expected to see the low/high portions of that address, NOT 0x2a and 0x6a: what am I doing wroing?
3. Any suggestions, or problems you can detect, based on the information provided?
