PROCESSOR-SDK-AM65X: OSPI boot not working

Hello,

I am wondering if you could please share the OSPI boot instructions that you used. Here are the instructions found in Uboot: http://git.ti.com/cgit/cgit.cgi/ti-u-boot/ti-u-boot.git/tree/board/ti/am65x/README?h=ti-u-boot-2019.01. Also, could you please confirm if you have tested the same setup on earlier SDK?

Regards,
Krunal

Hi Krunal,

The process is same as described in the README and we have tried previous SDK(5.3) which is OK. Thanks.

Hello,

On my board, I just tried OSPI boot and it worked without any problems. Here are the commands I used:

=> mmc rescan   
=> sf probe
SF: Detected mt35xu512aba with page size 256 Bytes, erase size 128 KiB, total 64 MiB
=> fatload mmc 1 ${loadaddr} tiboot3.bin
121604 bytes read in 13 ms (8.9 MiB/s)
=> sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x1db04
121604 bytes written, 0 bytes skipped in 0.173s, speed 707514 B/s
=> fatload mmc 1 ${loadaddr} tispl.bin
480516 bytes read in 44 ms (10.4 MiB/s)
=> sf update $loadaddr 0x80000 $filesize
device 0 offset 0x80000, size 0x75504
480516 bytes written, 0 bytes skipped in 0.703s, speed 696952 B/s
=> fatload mmc 1 ${loadaddr} u-boot.img
931604 bytes read in 83 ms (10.7 MiB/s)
=> sf update $loadaddr 0x280000 $filesize
device 0 offset 0x280000, size 0xe3714
931604 bytes written, 0 bytes skipped in 1.400s, speed 679944 B/s
=> fatload mmc 1 ${loadaddr} sysfw.itb
265822 bytes read in 26 ms (9.7 MiB/s)
=> sf update $loadaddr 0x6c0000 $filesize
device 0 offset 0x6c0000, size 0x40e5e
265822 bytes written, 0 bytes skipped in 0.504s, speed 536887 B/s
=>

After updating the SPI, I used the following page to change my boot pins and here is the boot log:

U-Boot SPL 2019.01-g8b90adfb16 (Jul 07 2019 - 05:46:46 +0000)
SYSFW ABI: 2.6 (firmware rev 0x0013 '19.4.1-v2019.04a (Curious Crow)')
Trying to boot from SPI
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.1(release):ti2019.01-rc2
NOTICE:  BL31: Built : 04:28:26, Jul  7 2019
I/TC: 
I/TC: OP-TEE version: 3.2.0-583-g251f7c6-dev #1 Sun Jul  7 04:40:43 UTC 2019 aarch64
I/TC: Initialized

U-Boot SPL 2019.01-g8b90adfb16 (Jul 07 2019 - 05:09:26 +0000)
i2c_write: error waiting for data ACK (status=0x116)
Reading daughtercard EEPROM at 0x52 failed -121
i2c_write: error waiting for data ACK (status=0x116)
Reading daughtercard EEPROM at 0x52 failed -121
detected SER-PCIEUSBEVM
Trying to boot from SPI
cannot find image node 'k3-am654-pcie-usb3.dtbo': -1


U-Boot 2019.01-g8b90adfb16 (Jul 07 2019 - 05:09:26 +0000)

Model: Texas Instruments AM654 Base Board
DRAM:  4 GiB
MMC:   sdhci@4f80000: 0, sdhci@04FA0000: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
i2c_write: error waiting for data ACK (status=0x116)
Reading daughtercard EEPROM at 0x52 failed -121
i2c_write: error waiting for data ACK (status=0x116)
Reading daughtercard EEPROM at 0x52 failed -121
detected SER-PCIEUSBEVM
Net:   
Warning: cpsw_nuss@046000000 using MAC address from ROM
eth0: cpsw_nuss@046000000, eth1: pruss2_eth
Hit any key to stop autoboot:  0 
=> 

Regards,
Krunal

Hi 

The version of our EVM board is ‘ASSM #: 4P0081 REV:1.0’，please confirm whether the version of your EVM board is the same as it, thank you

Hello,

Yes, I have the same revision and I have tried 2 different boards (socketed + non-socketed) but I am unable to replicate your errors. For my testing, I am using the pre-built images from the SDK and I am wondering if you have modified any images. Also, while booting from SPI, are you observing any serial output on the console?

Regards,
Krunal

Hello,

We use the pre-built images too, but it really can't boot from ospi flash, I have tried it many times and the console does not output anything!

Hello,

I am wondering if you could please share the full SD card boot log and the steps that were used to flash the SPI. Also, is it possible to try another board or are you observing the same behavior on multiple boards?

Regards,
Krunal

Also, if possible, please connect to the R5 core in CCS(no gel file) and share the program counter value.  As an experiment, please navigate to the file <u_boot>/arch/arm/mach-k3/am6_init.c and add the following test print code:

          early_console_init();
  #endif
~         printf("Test print\n");
  #ifdef CONFIG_K3_LOAD_SYSFW
          /*
           * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
           * regardless of the result of pinctrl. Do this without probing the
 

After compiling/loading the Uboot images, please open the MCU_UART and you should observe the printf statement upon boot.

Regards,
Krunal

Hello,

The main difference is we are not using min config pin but manually setup the boot configures.

But we still have question, the only difference is the min bit, all the other configuration is exactly the same to the default value(min config enabled) .

I'm not sure why we must enable this min bit for the new SDK 6.0.

More info, on the u-boot code side, if we are not using the minimal configuration, the processor will hang at sysfw-loader.c when trying to load sysfw from SPI flash. It seems that the device was not fully initialized before accessing. I suggest that the SPI interface should be reinitialize using DTS and keep independent with the ROM code stage. If not, for pure SPI flash boot will just fail with current u-boot design.

Thank you.

Hello,

The min config pin is required on Uboot 2018.01+Uboot 2019.01 and on my setup, I was not able to boot without it. If the pin is not set, the following default configurations will not be setup:

Regards,
Krunal

Hi Krunal,

My idea is even the reset of the configs is exactly the same with what the min config pin does, the board could not boot.

Also, most importantly, seems that the current u-boot won't support pure SPI flash boot( bus width = 2 )

Best Regards

Hello,

I was able to replicate your error with the min pin bit. We have filed an internal ticket to update the TRM but the boot pins [15:8] should be configured as follows:

Regards,
Krunal