• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 103 subscribers
  • Views 1492 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problems about host enumerating C6678 DSPs

Nuoxi Lin
Intellectual 650 points

Hi everyone,

    I am using a custom board on which there are two C6678 DSPs(PG1.0) , two FPGAs and a pcie switch.

Both the DSPs and FPGAs are connected to the pcie switch.And  the pcie switch is connected to a PC host

whose operation system is windows XP. The two DSPs were set as End-point mode . Their pcie initialization

codes were flashed into EMIF nor flash. We  used EMIF boot mode.  

Our purpose is that the host can enumerate the devices once powed on. But only the FPGAs can be

enumerateend successfully, two DSPs can't be   enumerated.

According to  some posts earlier , i try to use pcie boot mode,but it fails ,too.

    Here are my questions:

1. Must  the boot mode be set as pcie boot for the host to enumerate DSPs successfully?

2. If the answer for question 1 is yes , then what should  i do to boot up C6678 DSP in pcie boot mode  for the case of custom board?

If i writte IBL to EEPROM, then the FPGA program in my board must be modified to force the DSP to boot from i2c first,right?

Is there any other solutions?     

 The library version I use is mcsdk_2_00_09_21 and pdk_C6678_1_0_0_21.

Hope someone helps. Thank you in advance.

Nuoxi

Best Regards

  • 0
    Intellectual 650 points

        Some supplements of my former questions .I downloaded a folder named secondyBoot_PLLfix from

    http://processors.wiki.ti.com/images/4/4d/SecondaryBoot_PLLfix.zip.

    Can someone tell me the procedures to use it to implement pll fix? The readme.txt contained is so compendairy


    that I still don't know how to do .

    For example, the readme.txt says:

    Step 1: Compile the Utilities using the in the Utils\utils_src using "make all"

    Where to find the command "make all"? My PC operating system is windows XP.

    Hope someone helps. Thank you very much.

    Nuoxi

    Regards

     

  • 0
    TI__Genius 12065 points

    Nuoxi,

    1. The PCIe boot mode basically initializes the PCIe module and configures it as EP mode. And it also starts the link up training (set LTSSM_EN bit in CMD_STATUS register) for the host/RC to establish the link up between the two devices for enumeration. 

    2. You can setup the boot strap pins mentioned in the C6678 user guide to configure it to PCIe boot mode. If you use other boot mode, please make sure the PCIe initialization and link up training starts before host/RC to enumerate the device. 

    In your case, you probably can connect the DSP to CCS and check if the PCIe init code is running correctly and if the PCIe registers has been setup correctly.

    3. The IBL update may require the boot from I2C as mentioned in the MCSDK document.

    When connecting the PCIe EVM to PC host, the IBL update may be required for some EVM revision.

    Please take a look at some previous posts to see if they help. Thanks.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/191930/698130.aspx#698130

  • 0 in reply to Steven Ji
    Intellectual 650 points

    Hi Steven,

        Thank you very much for your reply. Here are my procedures in detail.

    1. After setting the boot strap pins to EMIF boot mode, I connected the DSP to CCS and ran the pcie initialization code .

        I have checked the pcie init code was running correctly and the pcie registers were setup correctly.

        The value of LTSSM_EN bit in CMD_STATUS register was 1.

    2. I  flashed the pcie init code to EMIF nor flash ,then powed on the board. Some LEDs were off ,which implied the DSPs

        have linked with pcie switch.

         By looking up the memory of DSP, I found the value of LTSSM_EN bit in CMD_STATUS register was 1.

    3. I connected  the pcie switch and the host PC with a cable ,then  powered on the host PC and our board simultaneously.

       (If I power on our board first ,then the host PC can not start up. )

       The following phenomena  occured.

        First, the LEDs turned off,which indicated  the link between DSP and pcie switch has been setup. But the host PC couldn't be started up.

        Then, the LEDs turned on,which indicated  the link between DSP and pcie switch has been cut. But the host PC could be started up now.

        Running  the WinDriver on host PC, I found FPGAs had been enumerated but DSPs was not enumerated.

        At last , I connected  the DSP with CCS and looked up memory,  the value of LTSSM_EN bit in CMD_STATUS register was 0.

        Here are my questions.

        1) I think LTSSM_EN bit in CMD_STATUS register becoming 0 is the cause for host can't enumerate DSPs.

        But how to solve this problem? Do you have some suggestions?

        2) I have verified that EMIF boot mode doesn't require PLL fix.

        So if i use EMIF boot mode, I need not consider pll fix for the purpose of enumerating DSPs, right? Please confirm.

        I am looking forward to your replies. Thank you .

    Nuoxi

    Regards

     

  • 0 in reply to Nuoxi Lin
    TI__Genius 12065 points

    Nuoxi,

    1. LTSSM_EN bit is only used to start the link up training. Regarding to the status of the link, we should monitor LTSSM_STATE field in DEBUG0 register. If LTSSM_STATE=0x11, it means the PCIe link is up (refer to A.1 LTSSM States section in PCIe user guide). If it is other than 0x11, it means the PCIe link could not be established due to some reasons. 

    Based on your description, it looks like there is some conflict between PC/host and the link between DSP and PCIe switch. 

    Do you observe the DSP PCIe link will up first (LTSSM_STATE=0x11) and then be dropped (LTSSM_STATE=other values) because of the PC power up please?

    If you see the link is broken, are you able to set LTSSM_EN=1 again to re-trigger the link up training on DSP please?

    2. Based on the Advisory 8 in C6678 errata, the PLL fix should be applied no matter which boot mode is. You can use silicon revision 2.0 which already has the fix.

    The IBL in the MCSDK package should have the PLL fix and some PCIe fix (mainly to accept spread spectrum clock) as mentioned in the BiosMulticoreSDK_xx_user guide.

    The following page has some details of the IBL update procedure as well. It might be worth trying out to see if works for your case.

    http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#IBL

    But it is interesting to figure out why the link up was broken when power up the PC. And have you tried that with other PC/host please?

  • 0 in reply to Steven Ji
    Intellectual 650 points

    Hi Steven,

        Thank you for your detailed reply.

    Steven Ji said:

    Do you observe the DSP PCIe link will up first (LTSSM_STATE=0x11) and then be dropped (LTSSM_STATE=other values) because of the PC power up please?

       

    Yes , I observed  that the DSP PCIe linked up first (LTSSM_STATE=0x11) and then dropped(LTSSM_STATE=0x0)because of the PC power up .

     

    Steven Ji said:

    If you see the link is broken, are you able to set LTSSM_EN=1 again to re-trigger the link up training on DSP please?

    At the end of  my pcie init code(PCIE Uses Cases for Keystone Devices.pdf is referenced), I set  LTSSM_EN=1 many times

     to re-trigger the link up training on DSP , but the phenomena are the same.

    while((DEBUG0&0x1F)!= 0x11){ }; //wait for L0 state

    for(i = 0; i < 1000000; i++) //re-triger

    {

        for(j = 0; j < 1000000; j++)

    {

        CMD_STATUS |= 0X1;

    }

    }

     

    Steven Ji said:

    But it is interesting to figure out why the link up was broken when power up the PC. And have you tried that with other PC/host please?

    Yes, it did not work on other PC/host,either. I agree with your opnion that there are some conflicts.

    But i don't know what they are and how to resolve them yet.

        Also, I am modifying IBL code to fit our custom board. Hope it will link up after updating IBL into I2C EEPROM.

        Here I have another qustion. If I power on our board only, the value of LTSSM_STATE is 0x11.Then I give the DSP a hot

    reset,then the value of LTSSM_STATE will be  0x0. Is this resonable? 

       I am looking forward to your reply. Thank you.

    Nuoxi

    Regards

     

     

     

     

     

  • 0 in reply to Nuoxi Lin
    TI__Genius 12065 points

    Nuoxi,

    1. I am wondering if you still miss the enumeration point that your iterations finishes before the PC host starts scanning the bus, or you are doing too much re-triggering and interrupt the enumeration itself.

    I think you could add some delay (maybe 1ms/5ms) before each re-triggering and check the link status after each re-triggering as well to see if any luck.

    It seems tricky to control the timing. I am wondering if there is BIOS setup in the PC host to stop inserting the reset (which seems to interrupt the link up) after the power up.

    2. I am not sure what DSP hot reset you are referring to. If it is hard/soft reset that toggles RESETSTATz, the PCIe module will be reset (link broken) based on the description of data manual and PCIe user guide. If it is CorePac local reset (NOT toggles RESETSTATz), it should not affect PCIe or other peripherals.

  • 0 in reply to Steven Ji
    Intellectual 650 points

    Hi Steven,

        Sorry for the long delay.  

        I updated IBL to apply to our board and have implemented pcie bootmode. Now we use pcie bootmode.

    The cause for enumeration failure is that pcie switch has used a SSC ,but  DSP and swtich doesn't use a

    common clock source. Now the PC host can enumerate two DSPs and allot resources to them. Run

    software WinDriver on PC side and you can see the memory space PC distributes to DSPA is as follows.

    BAR0    0xFE70 0000---0xFE7F FFFF     SIZE:1M

    BAR1    0xFE68 0000---0xFE6F FFFF     SIZE:512K

    BAR2    0xFE00 0000---0xFE3F FFFF     SIZE:4M

    BAR3    0xFA00 0000---0xFAFF FFFF      SIZE:16M

    BAR4   0xF9FF E000---0xF9FF FFFF 

    BAR5   0xF9FE 0000---0xF9FE FFFF 

    However,it fails everytime i read and write memory in WinDriver. It often returns oxFFFFFFFF or 0x0.

    It means PC host fails to write to DSP.

       Then i modified function  iblPCIeWorkaround() ,which mainly sets up pcie registers. Its location is

    mcsdk/ boot_loader/ ibl / src / device / C66x / C66xinit.c. I added the following codes.

    //Inbound.   Only set BAR1.

    DEVICE_REG32_W((PCIE_BASE_ADDR + IB_BAR0) ,0x1); //BAR1 is selected for inbound region 0

    DEVICE_REG32_W((PCIE_BASE_ADDR + IB_START0_LO) ,0xFE680000);

    DEVICE_REG32_W((PCIE_BASE_ADDR + IB_START0_HI) ,0x0);

    DEVICE_REG32_W((PCIE_BASE_ADDR + IB_OFFSET0) ,0x10840000);

    DEVICE_REG32_W((PCIE_BASE_ADDR +BAR1) ,0xFE680000);

    //outbound

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

    {

    DEVICE_REG32_W((PCIE_BASE_ADDR +OB_OFFSET_INDEX0 + i*8) , 0X80000001 | i*0X800000);  //OB_SIZE : 8M

    DEVICE_REG32_W((PCIE_BASE_ADDR +OB_OFFSET_INDEX0_HI + i*8) , 0x0);  //32-bit address

    }

        After modifying this, the PC host can write to and read from DSP. However , if i set both  IB_START0_LO and BAR1 to

    0xFE080000(or any value except 0xFE680000) instead of 0xFE680000, then PC is not able to write to DSP.

    Questions:

    1. Should the register BARn be set up in ibl code? Or their value are distributed by PC host(RC) and User should not set them?

    2. In function  iblPCIeWorkaround() ,BAR0 MASK is set to 0x0000 0FFF,but BAR0 space occupies 1M memory,why?

    3. In the case that  PC host (RC) write to DSP(EP), are  there any suggestions when setting inbound and outbound registers?

        Hope you help. Thank you in advance.

    Regards,

    Nuoxi

  • 0 in reply to Nuoxi Lin
    TI__Genius 12065 points

    Nuoxi,

    1. Usually the BAR register are configured/distributed  by the host PCIe driver during the enumeration. And the driver will only use the predefined BAR setup pattern to access the   PCIe device memory. It may explain why 0xFE680000 is working while 0xFE080000 is not. Because the C66x has the Inbound translation registers to control the BAR region mapping to the internal memory, the user needs to set the inbound translation registers correctly to match what the BAR has been configured by the host driver.

    2. BAR0 is dedicated to PCIe application registers space and the BAR0 mask (window size) should be fixed in C66x PCIe module (as 1MB). The user could configure bits [31:20] of BAR0 values. The IBL does not need to have this Mask setup for BAR0.

    3. First, only the inbound translation registers need to be setup for the inbound transfer (transfer initiated by the external device, no matter read or write). The outbound translation registers are only used for the outbound transfer (C66x PCIe initiates the transfer, no matter read or write).

    In your case, it is inbound transfer (host writes to DSP), and the WinDriver defines the BARn register values. We just need to configure the inbound translation based on those assigned BAR values from the driver and route the packets to the DSP internal memory defined in your application, just as what you described in your last post.

  • 0 in reply to Nuoxi Lin
    Prodigy 120 points

    Hello lin, I meet the same problem with you .

    As you say "I updated IBL to apply to our board and have implemented pcie bootmode. Now we use pcie bootmode.

    The cause for enumeration failure is that pcie switch has used a SSC ,but  DSP and swtich doesn't use a

    common clock source. Now the PC host can enumerate two DSPs and allot resources to them"

     what is SSC? what did you do to solve this problem . my C6678 use local clock ,not same with PC.

    can i have your email?

    my email: zhf-313@163.com

  • 0 in reply to Nuoxi Lin
    Intellectual 510 points

    Hello lin, I meet the same problem with you .

    As you say "I updated IBL to apply to our board and have implemented pcie bootmode. Now we use pcie bootmode.

    The cause for enumeration failure is that pcie switch has used a SSC ,but  DSP and swtich doesn't use a

    common clock source. Now the PC host can enumerate two DSPs and allot resources to them"

     what is SSC? what did you do to solve this problem . my C6678 use local clock ,not same with PC.

    can i have your email?

    my email: Wang09061200@163.com