• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 679 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.

PROCESSOR-SDK-J7200: Flash/Boot OSPI with sf commands

James Windorff
Prodigy 90 points
Part Number: PROCESSOR-SDK-J7200
Other Parts Discussed in Thread: DRA821U

Hello,

I am trying to boot out of the OSPI on the J7200 SDK 8.02, but first I am trying to flash through u-boot on the SD. 

I am trying to use the J7200 with the DRA821U mounted on it. I am booting with the SD card, then using u-boot to sf probe and sf update with TFTP as shown below. 

After having no apparent issues flashing, I am not able to boot. I have set the boot switches to:

Switch No. 1 2 3 4 5 6 7 8 9 10
SW8 OFF OFF OFF OFF ON OFF ON OFF OFF OFF
SW9 OFF ON ON OFF OFF OFF OFF OFF OFF OFF
SW3 OFF ON ON ON OFF OFF ON OFF ON OFF

The sf commands seem to run correctly, but when switching boot modes to OSPI, nothing shows up on the UART. 

I have a theory, but have not been able to confirm as the ospi_phy_pattern is in the dev kit already and sf erase is erroring. 
With our custom hardwarel, the phy pattern is not in the OSPI yet. I added a printout in sf probe that shows what is in memory at where the probe is looking (0x3fc0000). After some investigating, I found that the ospi_phy_pattern was written 1 byte later than it is supposed to be and with that we lose the last byte at the end. When reading back in while trying to configure, starting at 0x3fc0000 the order goes 0x00 0xFE 0xFF.... in stead of going right into 0xFE 0xFF..... With the same printout on the dev kit, the read back shows 0xFE 0xFF.... I did try to update it again and got the same results. Also, when running sf probe, shows a failed to find configuration file error directly related to this. 

I think this is why the OSPI boot is not working as I believe it is looking at offset 0x0 in the OSPI for the first file, and it is being written one byte later. 

Is there something I need to do differently or something that I am missing when flashing? Also, is sf update supposed to start one byte later than the address given to it? 

  • 0
    Prodigy 90 points

    I would like to note that the custom hardware uses the same OSPI part and similar circuitry.

  • 0
    Prodigy 90 points

    After some discussion, I also tried these switch settings: 

    Switch No. 1 2 3 4 5 6 7 8 9 10
    SW8 OFF OFF OFF OFF OFF ON ON OFF OFF OFF
    SW9 OFF ON OFF OFF OFF OFF OFF OFF OFF OFF
    SW3 OFF ON ON ON OFF OFF ON OFF ON OFF

    The first picture is a screen grab from this link: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/08_02_00_02/exports/docs/j7200/linux/Foundational_Components/U-Boot/UG-QSPI.html. With the sf commands that are supposed to be run

  • 0 in reply to James Windorff
    TI__Genius 10620 points

    James,

    I believe your latest posting of the dip switches to be the correct settings for OSPI, CS0, Primary Boot Mode.

    Thanks,

    Stuart

  • 0
    Prodigy 90 points

    Update: I was running the OSPI at a low speed without changing the parent clock. This is what caused the byte offset (and it was only for read). I put it back to the starting speed (25MHz) and the offset goes away, but I am still unable to boot vie OSPI with this programming method. 

  • 0 in reply to James Windorff
    TI__Genius 10620 points

    James,

    I've spent some time today to verify the image loading process on the OSPI FLASH as instructed by the U-Boot user's guide. I can get all of the images downloaded over tftp and loaded on to the SPI FLASH without any issue. I did have to "unlock" the sector of FLASH for the PHY calibration in order to flash it successfully.

    I am also not able to boot from the images loaded into the SPI FLASH. I am not getting any printout on any of the UART terminals (I opened all 6 just in case).

    My testing was with SDK version 8.02.00.02. I going to try the whole procedure again tomorrow using the latest SDK version 8.05.00.08. I looked over our issues database for any OSPI related issues. There have been a few OSPI related items around the 8.01 to 8.03 versions. My uneducated interpretation is that these issues should not affect the ability to boot. Nonetheless, I think trying the latest SDK will be a good sanity check.

    Thanks,

    Stuart

  • +1 in reply to Stuart Baker
    TI__Genius 10620 points

    James,

    I have had a bit of a breakthrough in debugging this issue. Please setup your DIP switches to the following settings, which work for me:

    SW.1 SW.2 SW.3 SW.4 SW.5 SW.6 SW.7 SW.8 SW.9 SW.10
    SW8 ON off off off off off ON off
    SW9 off off ON ON off off off off
    SW3 off ON ON ON off off ON off ON off

    This will change the bootmode to SPI (as opposed to OSPI). For some reason, it seems that the ROM works with SPI mode, but not OSPI mode. I believe only the first stage in ROM will use SPI, but later stages will use OSPI, improving performance.

    I'm not sure why OSPI in ROM does not seem to work. Perhaps one of our product experts can chime in. I will try and find out.

    Thanks,

    Stuart