Boot file example for C6455 with PCI initialization

When using the PCI Host boot mode, the PCI peripheral will be initialized in a pre-defined manner (default or from EEPROM) so that the PCI Host can access memory mapped locations in and around the DSP.

When using the Master I2C boot mode, the I2C peripheral will be initialized in a pre-defined manner and it will start reading as described in the Bootloader User's Guide. All other peripherals, including the EMIFs and the PCI will have to be directly initialized by the I2C boot process or by the code that gets loaded.

With the Master I2C boot mode, you can use the boot table format to write values to specific peripheral registers, or you can load code for the DSP and let the DSP execute the peripheral initialization as part of that downloaded code.

If this answers your question, please mark this posting with the Verify Answer button. Otherwise, please give us a little more information or explain what was missing that you still need.

Hello RandyP,

Thank you so much for your answer. Yes, we've initialized and configure PCI in the I2C boot process but it is not running. Could it be possible configure PCI peripheral in the DSP boot. We don't know how we can write a DSP boot in C? Do you know some document in which the procedure is explained? Any information/help will be very appreciated.

Many Thanks in advance,

Best Regards.

There are two documents on www.ti.com that describe how to work with the bootloader. Have you read these?

Bootloader User's Guide for the TMS320C645x/C647x

Preparing an C645x application for I2C Boot Load

These should contain sufficient information to build a useful bootloader image. But if you have read these and still have questions, please continue to explain the problem you need to solve.

Hello RandyP,

I've already read these two documents, but in none of them there are examples of creating a boot file for C6455. Do you know where I can find an example of a boot file (written in C or asm) which initializes the peripherals of C6455 (specially PCI controller)? Any help will be very appreciated.

Many Thanks in advance,

Kind Regards

Do you have an application program that you can successfully load through JTAG/CCS and that application program then successfully initializes PCI and allows you to use PCI how you want to use it?

Have you accessed the .zip file of example project files listed in the Abstract section at the beginning of "Bootloader User's Guide for the TMS320C645x/C647x"?

Have you been able to successfully boot the LED example from that zip file?

Hello RandyP,

Yes, we have an application program which configure PCI, and when we load this program through JTAG/CCS, the program succesfully initializes PCI and we can use correctly.

We don't find the .zip file of example project that you mention in your mail. Could you please indicate in which part of the document is located this .zip file?Are there any boot file example in which the PCI is initialized and configured in C6455?

Many Thanks in advance,

Kind Regards

Hi Francisco,

why you want to boot from the I2C? We had  problem to configure the PCI from I2C too. The table at 0x400 in i2C allow you to configure only a part of PCI-Backendregister i.e you are not able to define the adressspaces as you want. Thats why we prefered a EMIFA-Bootmode, so we are able to place the whole configuration code for PCI into the flash.  that seems to be more stable.

May be there there is also conjunction in  your case to erratta 2.1.12 PCI-Reset in Siiconerrata (sprz234) . I had sometimes the assumption that a PCI-Reset clears the Backendregister, but not restart the initiliziation from I2C-Eeprom. Is this possible?

We also had the exerience that the behevior if newer Chipset on x86 like ICH8 show a different behavior in PCI--reset  while starting the system.

Best regards
Bernhard W.

Francisco,

I left for two weeks on June 8 so this is my first chance to respond. I have been searching old versions of the bootloader document and anything else I can think of, but cannot figure out what I was referencing. There is no example zip file in the documents or in my file database. My sincere apologies. I must have been confused with other boards that can plug into a PC's PCI slot, and for those we usually supply an example for running from the PC.

I did find one that may help by similarity for the DM647/8, Using the TMS320DM647/DM648 Bootloader. The DM647 does support PCI boot, I2C initialization, and I believe it is the same (or very similar) PCI peripheral as the one in the C6455. In most cases I have seen, users do not use I2C initialization for PCI because the defaults work okay. If you only have one C6455 in your system, that should be true.

I may still be confusing what you actually need. You have an application that runs successfully when booted by loading from JTAG/CCS, but when you try to place the application into the boot image for I2C boot, you are not able to successfully access the PCI peripheral. Is this correct?

The leading cause for this kind of behavior is that there is some initialization done in the GEL file that CCS uses when it loads your application. If any of that initialization is not done, such as for PLLs and some peripherals, then the application is not yet completely standalone. Can you try removing the GEL file from your CCS setup (make a note of the full path for later restoration)? Then disconnect JTAG, power cycle the board, reconnect JTAG and try to load the program the same way that the bootloader will do. It may be more complicated than this, since some of our bootloaders do a small amount of initialization themselves - refer to the Bootloader manual to be sure, and some functionality might need to be added back in through a shortened GEL file.

Hello RandyP,

Thank you very much for your answer. I haven't solved our problem yet. As you commented, you has described my problem perfectly:

I have an application that runs successfully when booted by loading from JTAG/CCS, but when I try to place the application into the boot image for I2C boot, I'm not able to successfully access the PCI peripheral.

Is it possible that our boot is not running ok? or is it possible that we are not initializing correctly PCI in our boot file. You can see below our boot file:

            .title  "Flash bootup utility for 6455 dsp"
            .option D,T
            .length 102
            .width  140

COPY_TABLE        .equ       0xB0000400

PERLOCK            .equ    0x02AC0004
PERCFG0            .equ    0x02AC0008

DIR_LED            .equ    0x02B00010
SET_DATA_LED    .equ    0x02B00018
OUT_DATA_LED    .equ    0x02B00014       

            .sect ".boot_load"
            .global _boot

_boot:     

            zero B1
_myloop:  ; [!B1] B _myloop 
            nop  5
_myloopend: nop


;****************************************************************************
;* Copy code sections
;****************************************************************************
FAIL_A:
        ; Cargar los registros 'a' con un valor determinado
        mvk -1,  a1
        mvk    -2,  a2
        mvk -3,  a3       
        mvk -4,  a4
        mvk  5,  a5
        mvk  6,  a6
        mvk  7,  a7
        mvk  8,  a8
        mvk -9,  a9
        mvk -10, a10
        mvk -11, a11
        mvk -12, a12
        mvk  13, a13
        mvk  14, a14
        mvk  15, a15
        mvk  16, a16
        mvk -17, a17
        mvk -18, a18
        mvk -19, a19
        mvk -20, a20
        mvk  21, a21
        mvk  22, a22
        mvk  23, a23
        mvk  24, a24
        mvk -25, a25
        mvk -26, a26
        mvk -27, a27
        mvk -28, a28
        mvk  29, a29
        mvk  30, a30

        ; Suma acumulativa de los registros 'a' en a31
        add a1,  a2,  a31
        add a31, a3,  a31
        add a31, a4,  a31
        add a31, a5,  a31
        add a31, a6,  a31
        add a31, a7,  a31
        add a31, a8,  a31
        add a31, a9,  a31
        add a31, a10, a31
        add a31, a11, a31
        add a31, a12, a31
        add a31, a13, a31
        add a31, a14, a31
        add a31, a15, a31
        add a31, a16, a31
        add a31, a17, a31
        add a31, a18, a31
        add a31, a19, a31
        add a31, a20, a31
        add a31, a21, a31
        add a31, a22, a31
        add a31, a23, a31
        add a31, a24, a31
        add a31, a25, a31
        add a31, a26, a31
        add a31, a27, a31
        add a31, a28, a31
        add a31, a29, a31
        add a31, a30, a31

        ; Compara la suma con '1'
        cmpeq 1, a31, a0

 [a0]    b    RIGHT_A    ; Si el resultado coincide -> Se continúa
 [!a0]    b    FAIL_A    ; Si no coincide -> Se vuelve al principio


RIGHT_A:
        ; Se cargan los registros 'b' con los valores de los 'a'
        mvd    a1,  b1
        mvd    a2,  b2
        mvd a3,  b3       
        mvd a4,  b4
        mvd a5,  b5
        mvd a6,  b6
        mvd a7,  b7
        mvd a8,  b8
        mvd a9,  b9
        mvd a10, b10
        mvd a11, b11
        mvd a12, b12
        mvd a13, b13
        mvd a14, b14
        mvd a15, b15
        mvd a16, b16
        mvd a17, b17
        mvd a18, b18
        mvd a19, b19
        mvd a20, b20
        mvd a21, b21
        mvd a22, b22
        mvd a23, b23
        mvd a24, b24
        mvd a25, b25
        mvd a26, b26
        mvd a27, b27
        mvd a28, b28
        mvd a29, b29
        mvd a30, b30

        ; Suma acumulativa de los 'b' en b31
        add b1,  b2,  b31
        add b31, b3,  b31
        add b31, b4,  b31
        add b31, b5,  b31
        add b31, b6,  b31
        add b31, b7,  b31
        add b31, b8,  b31
        add b31, b9,  b31
        add b31, b10, b31
        add b31, b11, b31
        add b31, b12, b31
        add b31, b13, b31
        add b31, b14, b31
        add b31, b15, b31
        add b31, b16, b31
        add b31, b17, b31
        add b31, b18, b31
        add b31, b19, b31
        add b31, b20, b31
        add b31, b21, b31
        add b31, b22, b31
        add b31, b23, b31
        add b31, b24, b31
        add b31, b25, b31
        add b31, b26, b31
        add b31, b27, b31
        add b31, b28, b31
        add b31, b29, b31
        add b31, b30, b31

        ; Comparación de la suma con '1'
        cmpeq 1, b31, b0

 [b0]    b    RIGHT_B    ; Si el resultado coincide -> Se continúa
 [!b0]    b    RIGHT_A    ; Si no coincide -> Se vuelve a cargar los 'b'


RIGHT_B:
        zero B1
       
        mvkl  COPY_TABLE, a3   ; load table pointer
        mvkh  COPY_TABLE, a3

        ldw   *a3++, b1        ; Load entry point

copy_section_top:
        ldw   *a3++, b0        ; byte count
        ldw   *a3++, a4        ; ram start address
        nop   3
 [!b0]  b copy_done            ; have we copied all sections?
        nop   5
copy_loop:
        ldb   *a3++,b5
        sub   b0,1,b0          ; decrement counter
 [ b0]  b     copy_loop        ; setup branch if not done
 [!b0]  b     copy_section_top
        zero  a1
 [!b0]  and   3,a3,a1
        stb   b5,*a4++
 [!b0]  and   -4,a3,a5         ; round address up to next multiple of 4
 [ a1]  add   4,a5,a3          ; round address up to next multiple of 4

;****************************************************************************
;* Jump to entry point
;****************************************************************************
copy_done:
         
        b    .S2 b1
   
        nop   5

I've tried to perform the test that you mentioned and the result is the same. We're not using a GEL file in order to initialize our program. Any Idea? Could you please help? Any suggestion will be very appreciated!

Many Thanks in advance!

When you start CCS, can you load program or data into DDR2 memory space. For example, can you open a memory window and read/write to 0xE0000000? Do you have to manually do a Debug->Connect command?

Which version of CCS are you using?

How are the boot switches set for CCS/JTAG and for I2C boot?

Does your program image get loaded exactly the same both ways? After loading via CCS, save a memory image using the File->Data->Memory Save command, then after loading via I2C save a memory image and compare the two.

Are you trying to initialize PCI through the boot loader or in the program code that gets loaded by the boot loader?

The program that you show above, is that what gets loaded from I2C? If so, then from where do you read the rest of the program that the code above is trying to load? If not, how does this code get loaded and run, and still where does it try to read from?

Hello RandyP,

Thank you very much for your answers. I answer your questions below in red:

When you start CCS, can you load program or data into DDR2 memory space. For example, can you open a memory window and read/write to 0xE0000000? Do you have to manually do a Debug->Connect command?

Yes, I can open a memory window and read/write to 0xE0000000 without problems

Which version of CCS are you using? 

I'm using CCS 3.3

How are the boot switches set for CCS/JTAG and for I2C boot?

The boot switches performs directly when we restart the board and CCS is not connected

Does your program image get loaded exactly the same both ways? After loading via CCS, save a memory image using the File->Data->Memory Save command, then after loading via I2C save a memory image and compare the two.

The program that I load on DSP via emifa from flash is the hex code obtained with hex6x tool.

Are you trying to initialize PCI through the boot loader or in the program code that gets loaded by the boot loader?

We try to initialize PCI in the program code. Is it possible to initialize PCI through the boot loader? or in the boot program?

The program that you show above, is that what gets loaded from I2C? If so, then from where do you read the rest of the program that the code above is trying to load? If not, how does this code get loaded and run, and still where does it try to read from?

First, we load a configuration in EEPROM with boot parameter table. This configuration indicates that the program is located in a FLASH memory (hex program) Afterwards, the program saved in a flash memory is loaded in DSP memory. Our boot (the program shown before is located in FLASH with the other part of the program

Many Thanks in advance!

Hi Francisco,

I had a look to your code and I didn't found a initialiszation of EMIFA. Where you are setting  EMIF parameter?
If you have also placed some application-code in DDR-Memory you have to initalize it also in the bootloader.
You have to take care, that DDR-Memory will not be initialized a second time in the application you load. That can cause instability of your application-code in ddr memory.

Best regards

Bernhard W.

Hi Bernhard,

Thank you very much. The initialization of EMIFA is configured directly in the EEPROM parameters via "Boot Parameter Table" Configuration Mode. Do you know if I have to initialize PCI and DDR - memory in our boot file? How do we can achieve that? Do you have any example (a boot file in which PCI and DDR are initialized and configured)? Any help will be very appreciated!

Many Thanks in advance!

Kind Regards

Hi Francisco,

we initialize only DDR memory in our bootloader. The initilization of PCI is made  by the appliction , started by the bootloader. We set the PCI parameter before DSP/BIOS is started. The bootloader is localized in EEPROM connected to EMIF. DSP is configured to boot form EMIF.
I attach you a boot.asm file.

If you goto
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/50107.asp
you can find some other example code.

Best regards
Bernhard W.

Hi Bernhard!!

Thanks a million!!! Your help is very appreciated. I've tried the link but it seems that it's broken. Could you please try?

I've tested with your boot file and I obtain the same result. Is it possible that CCS v3.3 is initializing PCI in a some way, for example using a GEL file? I don't know if it is important but I'm not using DSP/BIOS in our program. Maybe does it have an effect in PCI initialization? I'm desperated with this problem :-(

Many Thanks in advance!

Kind Regards!

Hi Fransisco...

I don't see any initialization of PCI in  standard ccs3.3 gel file  (i.e. DSK6455.gel ). Except EMIF and PLL. but  I,m sure you've already checked this.

Perhaps I can help you more if you answer me some questions:
- Do you use the DSK board or a own hardware?
- Whats about the device configuration pins? Are all relevant pins set in the right way?
- Is  PCI (Bit 20 )  enabled in the device status registers?
- Some PCI pins are shared with GPIO. There is no conflict?
- Are you able to access the PCI registers in PCI register window?
- Which source of me you've used. Only boot.asm or also the sources of the link?

Best regard
Bernhard W.