This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EVM6678LE PCIe boot example test fails on Linux host PC

hi there

May be someone have similar trouble or can suggest any idea?

Problem description:

After linux host boots,  "lspci -n" don't show the TI board. If I push "Full Reset" on TI board several times, then issue "echo 1 > /sys/bus/pci/rescan",

I could see the board:

lspci -v -d 104c:*

01:00.0 Multimedia controller: Texas Instruments Device b005 (rev 01)
            Flags: bus master, fast devsel, latency 0, IRQ 16
            Memory at 80900000 (32-bit, non-prefetchable) [size=1M]
            Memory at 82400000 (32-bit, prefetchable) [size=512K]
            Memory at 82000000 (32-bit, prefetchable) [size=4M]
            Memory at 81000000 (32-bit, prefetchable) [size=16M]
            Memory at 82490000 (32-bit, prefetchable) [size=4K]
            Memory at 82480000 (32-bit, prefetchable) [size=64K]
            Capabilities: [40] Power Management version 3
            Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
            Capabilities: [70] Express Endpoint, MSI 00
            Capabilities: [100] Advanced Error Reporting

 

The attempt to execute PCIe demo fails (insmod hangs up), the command is "insmod pciedemo.ko".

After some debug I found the exact place where demo hangs:

<pciedemo.c>

#if HELLO_WORLD_DEMO

                /* Load DDR init code into DSP */

                pushData(ddrInitCode, 0, &bootEntryAddr);

                /* Write boot entry address into MAGIC_ADDR */

                writeDSPMemory(0, MAGIC_ADDR, &bootEntryAddr, 4);       

                while (1) {

/* <<<<<  Here this demo hangs forever >>>>>*/

                        readDSPMemory(0, MAGIC_ADDR, buffer, 4);

                        if (buffer[0] == 0)  break;

                        for (i = 0; i < 1000; i++) i++;

                } 

                /* Load "Hello World" demo into DSP */

                pushData(bootCode, 9, &bootEntryAddr);

                /* Write boot entry address into MAGIC_ADDR */

                writeDSPMemory(0, MAGIC_ADDR, &bootEntryAddr, 4);

#endif

Also  any attempt to read from TI device’s memory by means of io-mem returns 0xffffffff. I. e. any pci memory access, directly, or through

linux API ("ioread32()") returns only FFs. But I can read and write all the config space and application registers by means of io-port access.

I. e. linux functions like"pci_read_config_dword()" are works fine. 

My conclusion: the inbound address translation or memory access via PCIe is not working, while io-port access to entire PCIe config

space is working, but not stable. I checked all the BAR and IB_XXX register contents, all values were set according to the manual.

 

Here some details:

Board Name: TMDXEVM6678LE Rev 1.0 / PCB Rev A102-1

Board Serial Number: EPD0061817

Board additions: AMC to PCIe Adapter, BlackHawk XDS560v2 USB Mezzanine

AMC to PCIe S/N: 0058  PCB REV: 17-00107-03   PCA REV: 18-00107-03

DIP switch configuration:

SW3: (off, on, on, off)

SW4: (on, on, on, on)

SW5: (on, on, on, off)

SW6: (off, on, on, on)

SW9: (off/on, on)

Firmware used: MCSDK_02_01_02_06

 Linux on the host - tried SuSe 11.3 and Ubuntu 10.2

 Board POST test completes succesfully.

 

I also read and tried all suggestions in

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/247997.aspx

with no positive result.

Regards,

Dmytro

  • Dmytro,

    Could you double check the IB_xxx registers again to see if it is similar as below:

    The IB_BAR 1 (the second row) is used to mapping local L2. In your case, it may look like: 0x00000001 0x82400000, 0x00000000 0x10800000, since the BARn register is assigned by Linux host dynamically.

    And please also check if DDRINIT loaded correctly or not, inside the pcieddrinit_6678.h file (loaded to DSP via PCIE), 

    uint8_t ddrInitCode[] = {

    0x10, 0x82, 0xCA, 0xA0, 0x00, 0x00, 0xD2, 0xA0, 0x10, 0x82, 0x00, 0x00, 0x02, 0x04, 0x03, 0xE2, 0x92, 0x46, 0x0C, 0x6E, 0x00, 0x8C, 0xA3, 0x62,

    0x02, 0x28, 0x03, 0xE2, 0x92, 0x46, 0x0C, 0x6E, 0x00, 0x8C, 0xA3, 0x62, 0x02, 0x44, 0x03, 0xE2, 0xE2, 0x40, 0x00, 0x00, 0x92, 0x46, 0x0C, 0x6E,

    0x00, 0x8C, 0xA3, 0x62, 0xDC, 0x45, 0x8C, 0xF7, 0xBC, 0x4D, 0xAC, 0x45, 0x02, 0x81, 0xC0, 0x2A, 0x02, 0x81, 0x04, 0xEA, 0x00, 0x00, 0x20, 0x00,

    0xE1, 0xA0, 0x00, 0x00, 0x02, 0x14, 0x9E, 0x42, 0x6C, 0x6E, 0x10, 0x4D, 0xCC, 0x3D, 0xFC, 0x45, 0x00, 0x00, 0x60, 0x00, 0x02, 0x0C, 0x02, 0x56,

    ……

     

    The yellowed position is the address of the first section, that is: starting at 0x10820000, the data 0x02, 0x04, 0x3, 0xe2 was loaded. Then at next address 0x10820004, 0x92, 0x46, 0x0c , 0x6e was loaded. ….

    You can check them with DSP memory window. 

  • Sorry for delay, I checked memory and obtain exact values for IB_XXX as you specified

    Steven Ji said:

    Dmytro,

    Could you double check the IB_xxx registers again to see if it is similar as below

    The IB_BAR 1 (the second row) is used to mapping local L2. In your case, it may look like: 0x00000001 0x82400000, 0x00000000 0x10800000

    My values are:

    As for DDR - now for simplicity I am not touching DDR at all. I use modified example module just for checking

    possibility of configuration and local L2 memory access via io-mem. And such access is impossible.

    Is there any chance that I've got hardware defect on my EVM? And is it possible to exchange the board?

  • The IB registers setup seems fine.

    You may want to check with another PC or another EVM board to see if issue is reproducible.

    Please contact the sales support for the EVM exchange question. 

  • I have exactly the same problem.

    The insmod hangup

    IB register are good, the memory return 0xffffffff but I can read the bar 0 register.

    Any idea?