• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 431 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DRA829V: How can we change the peripheral value to 80 (QSPI) of Boot Parameter Table Common Header

DRA829V: How can we set the peripheral value to 80 (QSPI) of Boot Parameter Table Common Header

Hideaki Matsumoto
Genius 9100 points
Part Number: DRA829V
Other Parts Discussed in Thread: DRA829

Hi,

Since the following thread was locked, let me post another thread.

DRA829V: How can we change the peripheral value to 80 (QSPI) of Boot Parameter Table Common Header

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1215428/dra829v-how-can-we-change-the-peripheral-value-to-80-qspi-of-boot-parameter-table-common-header/4600860#4600860

As mentioned in the above thread, the customer set the BOOT pins as QSPI boot, and QSPI boot was done successfully. However, "Peripheral" was set as "85" OSPI, not "80" QSPI in the Boot Parameter Table Common Header described in the Table 4-51. in the page 1052 of DRA829 TRM.

Why is it ? How can they set it as QSPI "80" correctly ?

Regards,
Hideaki

  • 0
    TI__Guru 51053 points

    Hi Hideaki-san,

    Could you suggest customers to set the pins in XSPI mode, if they are using silicon revision 2.x? 

    https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_06_00_12/exports/docs/psdk_rtos/docs/user_guide/evm_setup_j721e.html#xspi-boot-mode-j721e-es2-x-versions-only. I have heard from colleagues that for silicon revision 2.x, this is the proper way to set the pins for OSPI. As a disclaimer, they have not tried this out for QSPI, but since these instructions are for XSPI, they should work for both OSPI and QSPI. 

    Other than boot pins, there should not be extra work needed to choose the right peripheral. An excerpt from the TRM for my reasoning: 

    And here are a couple of questions to help me understand what the issue is, which would greatly help us in supporting you:

    • Is the only issue the customer seeing the wrong value for "Peripheral"? And functionally, no issue is seen? For example, they are able to boot up, and see that their data is all stored and obtainable through QSPI. So the main reason of this E2E thread is to see if it is fine with this value that is different from TRM, and if TI determines that it is a typo in the TRM, the customer would be fine.
    • Which silicon revision device are they using? If they are using the newer 2.x device, the suggestion to use XSPI mode stands. 
    • Is there anything that the customer can share to make it easier for TI to reproduce the issue? For example, they have some documentation that they are following to reproduce the issue, or some binaries that they can share and register addresses that they are checking to verify the 80 vs 85 value. If not, we can try to reproduce the issue, but please set expectations with the customer that it will take a bit more time to reproduce the issue (maybe a day or two more)

    In parallel, what TI can do is:

    • Attempt to reproduce issue on our board - may take at max a week of time
    • Check with our internal ROM team to see if they have anything to comment on the behavior being seen by the customer

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    TI__Guru 51053 points

    Hi Hideaki-san,

    I checked with our ROM team and seems like I had a few misunderstandings that I would like to clear up:

    1. Takuma Fujiwara said:
      Could you suggest customers to set the pins in XSPI mode, if they are using silicon revision 2.x? 
    1. Do not suggest XSPI mode for QSPI. XSPI mode is only for OSPI mode and not for QSPI. I misunderstood the X in XSPI mode to be for "don't care" or can be Q or O. Instead, XSPI is a new standard that replaces OSPI in terms of performance, so it is different from QSPI mode.
  • There is only OSPI flash on the TI EVM, so only OSPI mode can be used when using TI EVM, and QSPI mode cannot be set on the TI EVM (even if it is set, it will not be able to boot). Is the customer using a custom board that has QSPI flash instead of OSPI flash on their board?

    • Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    TI__Genius 9100 points

    Takuma-san,

    Thanks for your reply.

    They need to identify the boot mode, becaue boot process has to be changed in the SBL.

    EVM has both OSPI Flash on OSPI0 and QSPI Flash on OSPI2, and either can be used by setting Boot pins. See the Figure 4-1. J721E EVM Functional Block Diagram in page 26 in the EVM User Guide.

    You can reproduce this issue easily by just booting from QSPI on EVM and checking the boot parameter table.

    Please check this.

    Thanks and regards,
    Hideaki

  • 0
    TI__Guru 51053 points

    Hi Hideaki-san,

    I am able to reproduce the issue as well. Behavior I see is that Linux kernel is able to boot properly from QSPI and everything is functional. As the customer has seen, I also see that 0x41CFFC04 address holds 0x55 instead of 0x50.

    As I check with the team on this, is the customer fine to continue on with their development, or is this a blocking issue?

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    TI__Genius 9100 points

    Hi Takuma-san,

    They need to fix this issue, because they want to switch the operations depend on the boot mode.

    Please solve this as soon as possible.

    Thanks and regards,
    Hideaki

  • 0
    TI__Guru 51053 points

    Hi Hideaki-san,

    Understood, but unfortunately, I think this might be a possible silicon errata if the ROM code is setting these registers. As a alternative, I suggest checking the physical port number defined in Table 4-60. OSPI/QSPI/SPI Boot Parameter Table of the TRM (or address 0x41cffd00).

    Here is a quick experiment I did for booting from OSPI vs QSPI and how the register address changes:

    QSPI boot:
    root@j7-evm:~# devmem2 0x41cffd00
    /dev/mem opened.
    Memory mapped at address 0xffff95e47000.
    Read at address  0x41CFFD00 (0xffff95e47d00): 0x01010001

    OSPI boot:
    root@j7-evm:~# devmem2 0x41cffd00
    /dev/mem opened.
    Memory mapped at address 0xffff814bf000.
    Read at address  0x41CFFD00 (0xffff814bfd00): 0x01010000

    And attached here is the relevant location of the TRM:

    I understand that this is not the ideal, but if customer knows which physical port the QSPI device is connected to, then this could be used to differentiate between OSPI and QSPI.

    Regards,

    Takuma

  • 0
    TI__Guru 51053 points

    Hi Matsumoto-san,

    Thank you for your patience. I was able to have a meeting with the ROM team to do an in-depth analysis on why QSPI is reporting back 85 instead of 80. We found out that in ROM, QSPI=OSPI=SPI=85 is set intentionally. Current alignment between ROM team and I is that this is a bug in the TRM.

    For the purpose of detecting whether the boot peripheral is OSPI vs QSPI, I got a suggestion from the ROM team to check the "Read Cmd" field in below table.

    For OSPI, this value should be 0x8b, QSPI 0x6b, and SPI 0x3. The main benefit of this method is that this is not board dependent like port number, which was the suggestion I made in my previous post.

    Regards,

    Takuma