AM6442: SPI boot fails on custom board with SDK 8.xx.

Koichiro Tashiro

Part Number: AM6442

Hi,

My customer reported SPI boot issue on the custom board with SDK 8.xx..

- SPI boot fails and stops at below point.

U-Boot SPL 2021.01 (May 12 2022 - 12:57:28 +0900)
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed -121
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
SPL initial stack usage: 13392 bytes
Trying to boot from SPI
spl_load_fit_image: Skip load 'dm': image size is 0!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 12:58:48, May 12 2022

U-Boot SPL 2021.01 (May 12 2022 - 13:22:09 +0900)
EEPROM not available at 80, trying to read at 81
i2c_write: error waiting for data ACK (status=0x116)
Reading on-board EEPROM at 0x51 failed -121
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
Trying to boot from SPI

- The issue observed on only custom board, not on TI EVM. TI EVM uses OSPI, QSPI is used on the custom board.
- SPI boot worked fine with SDK 7.xx even on the custom board.

Q1) Are there any changes made between SDK 7.x to 8.x in SPI boot?
Q2) Do we need to change anything in SW to use QSPI instead of OSPI?

Thanks and regards,
Koichiro Tashiro

over 3 years ago

0 Andrew Shutzberg over 3 years ago

TI__Intellectual 2360 points

Hey Koichiro,

Thank you for your question, my name is Andrew and I would be happy to assist with this. I have relayed your question to the team and hope to have a response for you within the next 1-2 business days. While I look into this, has there been any updates/developments to this problem on your end that we should take into consideration?

Best regards,

Andrew

0 Andrew Shutzberg over 3 years ago in reply to Andrew Shutzberg

TI__Intellectual 2360 points

Hey Koichiro,

Thank you for your patience, I do have some follow up questions:

1) What are the specifications of the custom board? I do know that the AM64x GP evm doesn't have support for QSPI installed by defualt, so it makes sense only OSPI would work on that board.

2) What tool(s) are you using to flash the images?

I found this similar post that covers these topics in greater depth, even touching on the process to enable QSPI support, but on a GP evm: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1008317/processor-sdk-am64x-trying-to-flash-qspi-from-uboot. Would this information be of use?

Best regards,

Andrew

0 Koichiro Tashiro over 3 years ago in reply to Andrew Shutzberg

TI__Mastermind 22915 points

Hi Andrew,

Sorry for my late reply.

Andrew Shutzberg said:
1) What are the specifications of the custom board? I do know that the AM64x GP evm doesn't have support for QSPI installed by defualt, so it makes sense only OSPI would work on that board.

As I mentioned, QSPI boot worked fine on the customer board with SDK 7.x. So something different in SDK 8.x.
And customer tested OSPI on GP EVM and observed below issue with SDK 8.x. Does OSPI boot work on GP EVM on your side? If so, please give the log.

U-Boot SPL 2021.01-00001-g911f54274e-dirty (May 31 2022 - 19:22:30 +0900)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Trying to boot from SPI
Starting ATF on ARM64 core...

Andrew Shutzberg said:
2) What tool(s) are you using to flash the images?

Customer uses below commands to write the image to QSPI.
After kernel boot:

# > dd if=tiboot3.bin of=/dev/mtdblock0
# > dd if=tispl.bin of=/dev/mtdblock1
# > dd if=u-boot.img of=/dev/mtdblock2

Customer also tried to use write in u-boot which was described in the E2E post you pointed.
But results were the same.
SDK 7.x => write in Kernel (or u-boot) worked.
SDK 8.x => write in Kernel (or u-boot) failed.

Thanks and regards,
Koichiro Tashiro

0 Andrew Shutzberg over 3 years ago in reply to Koichiro Tashiro

TI__Intellectual 2360 points

Hey Koichiro,

Thank you for your patience and the additional information. I have relayed your update to the team and hope to have a response from them shortly.

Best regards,

Andrew

0 Andrew Shutzberg over 3 years ago in reply to Andrew Shutzberg

TI__Intellectual 2360 points

Hey Koichiro,

Thank you again for your continued patience, just an update: I have reached out to an additional specialist to consult on this issue, and we hope to have a resolution shortly.

We do have one follow-up question as well:

Koichiro Tashiro said:
Customer also tried to use write in u-boot which was described in the E2E post you pointed.
But results were the same.

Did this create just the same end error, or was the entire debug log was no different than from previous attempts?

Best regards,

Andrew

0 Hong Guan64 over 3 years ago in reply to Andrew Shutzberg

TI__Guru 68290 points

Hi Koichiro-san,
The QSPI/OSPI flash layout offsets for the two u-boot binary (tispl.bin and u-boot.img) for AM64x EVM are defined in the two defconfig files.
The below is from SDK8.2, and the same two offsets were 0x80000, & 0x280000 before SDK 8.2
- SDK 8.2

- /configs/am64x_evm_r5_defconfig
CONFIG_SYS_SPI_U_BOOT_OFFS=0x100000		=> tispl.bin
- /configs/am64x_evm_a53_defconfig
CONFIG_SYS_SPI_U_BOOT_OFFS=0x300000		=> u-boot.img

It is necessary when porting customer board to
1/. modify the offsets to match the customer QSPI/OSPI flash layout
2/. use the same offsets for QSPI/OSPI flashing and booting

There's an early e2e post for your reference.
e2e.ti.com/.../1103450

Best,
-Hong

0 Koichiro Tashiro over 3 years ago in reply to Hong Guan64

TI__Mastermind 22915 points

Hi Hong,

Customer uses the same offsets in SDK7.x and it works with SDK7.x, but failing SDK8.x.
They also refer the E2E post you mentioned, but it fails with the same layout.

Could you send me QSPI boot logs for SDK8.0 and SDK8.2?
Customer wants to see successful logs.

Thanks and regards,
Koichiro Tashiro

0 Hong Guan64 over 3 years ago in reply to Koichiro Tashiro

TI__Guru 68290 points

Hi Koichiro-san,

Koichiro Tashiro said:
Could you send me QSPI boot logs for SDK8.0 and SDK8.2?
Customer wants to see successful logs.

I'm attaching two working log files I captured on AM64x EVM.
- am64_8.2_ospi_flash+boot.txt: OSPI flash from SD boot + OSPI boot (switch BOOTMODE pins) using SDK 8.2
- am64_8.0_ospi_flash+boot.txt: OSPI flash from SD boot + OSPI boot (switch BOOTMODE pins) using SDK 8.0
Hope they're helpful.
Best,
-Hong

0 Koichiro Tashiro over 3 years ago in reply to Hong Guan64

TI__Mastermind 22915 points

Hi Hong,

I could not see these txt files.
Could you double check these files are properly attached?

Thanks and regards,
Koichiro Tashiro

0 Hong Guan64 over 3 years ago in reply to Koichiro Tashiro

TI__Guru 68290 points

Attaching the two log files!

Fullscreen am64_8.2_ospi_flash+boot.txt Download

U-Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:43:41 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Reading daughtercard EEPROM at 0x52 failed -1
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.03.00.002-dirty
NOTICE:  BL31: Built : 17:38:37, May  5 2022

U-Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:42:22 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Reading daughtercard EEPROM at 0x52 failed -1
Trying to boot from MMC2


U-Boot 2021.01-g44a87e3ab8 (May 05 2022 - 17:42:22 +0000)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev E2
DRAM:  2 GiB
NAND:  1024 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Reading daughtercard EEPROM at 0x52 failed -1
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  2  0 
=> pri mtdparts
mtdparts=mtdparts=fc40000.spi.0:1m(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.phypattern)
=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> mtd list
List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x40000 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 256 bytes
  - OOB available: 142 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x000000000000-0x000040000000 : "nand0"
* nor0
  - type: NOR flash
  - block size: 0x40000 bytes
  - min I/O: 0x1 bytes
  - 0x000000000000-0x000004000000 : "nor0"
	  - 0x000000000000-0x000000100000 : "ospi.tiboot3"
	  - 0x000000100000-0x000000300000 : "ospi.tispl"
	  - 0x000000300000-0x000000700000 : "ospi.u-boot"
	  - 0x000000700000-0x000000740000 : "ospi.env"
	  - 0x000000740000-0x000000780000 : "ospi.env.backup"
	  - 0x000000800000-0x000003fc0000 : "ospi.rootfs"
	  - 0x000003f40000-0x000003f80000 : "ospi.phypattern"
=> mmc rescan
=> load mmc 1 ${loadaddr} tiboot3.bin
569866 bytes read in 29 ms (18.7 MiB/s)
=> sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x8b20a
45578 bytes written, 524288 bytes skipped in 1.421s, speed 409791 B/s
=> load mmc 1 ${loadaddr} tispl.bin
848243 bytes read in 40 ms (20.2 MiB/s)
=> sf update $loadaddr 0x100000 $filesize
device 0 offset 0x100000, size 0xcf173
   Updating, 31% 184238 B/s   Updating, 62% 179615 B/s   Updating, 93% 174535 B/s848243 bytes written, 0 bytes skipped in 5.807s, speed 149475 B/s
=> load mmc 1 ${loadaddr} u-boot.img
1116639 bytes read in 52 ms (20.5 MiB/s)
=> sf update $loadaddr 0x300000 $filesize
device 0 offset 0x300000, size 0x1109df
   Updating, 24% 189573 B/s   Updating, 47% 189439 B/s   Updating, 71% 181866 B/s   Updating, 94% 177243 B/s1116639 bytes written, 0 bytes skipped in 7.243s, speed 157802 B/s
=> md.l 0x43000030 1
43000030: 00000243                               C...
=> 
U-Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:43:41 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Reading daughtercard EEPROM at 0x52 failed -1
Trying to boot from SPI
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.03.00.002-dirty
NOTICE:  BL31: Built : 17:38:37, May  5 2022

U-Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:42:22 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Reading daughtercard EEPROM at 0x52 failed -1
Trying to boot from SPI


U-Boot 2021.01-g44a87e3ab8 (May 05 2022 - 17:42:22 +0000)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev E2
DRAM:  2 GiB
NAND:  1024 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Reading daughtercard EEPROM at 0x52 failed -1
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  2  0 
=> md.l 0x43000030 1
43000030: 00000273                               s...
=>

Fullscreen am64_8.0_ospi_flash+boot.txt Download

U-Boot SPL 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:42 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.00.00.004-dirty
NOTICE:  BL31: Built : 21:46:29, Aug 10 2021

U-Boot SPL 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:02 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
Trying to boot from MMC2


U-Boot 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:02 +0000)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev E2
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000
Hit any key to stop autoboot:  2  0 
=> pri mtdparts
mtdparts=mtdparts=fc40000.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.phypattern)
=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> mtd list
List of MTD devices:
* nor0
  - type: NOR flash
  - block size: 0x40000 bytes
  - min I/O: 0x1 bytes
  - 0x000000000000-0x000004000000 : "nor0"
	  - 0x000000000000-0x000000080000 : "ospi.tiboot3"
	  - 0x000000080000-0x000000280000 : "ospi.tispl"
	  - 0x000000280000-0x000000680000 : "ospi.u-boot"
	  - 0x000000680000-0x0000006c0000 : "ospi.env"
	  - 0x0000006c0000-0x000000700000 : "ospi.env.backup"
	  - 0x000000800000-0x000003fc0000 : "ospi.rootfs"
	  - 0x000003ec0000-0x000003f00000 : "ospi.phypattern"
=> mmc rescan
=> load mmc 1 ${loadaddr} tiboot3.bin
431102 bytes read in 22 ms (18.7 MiB/s)
=> sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x693fe
   Updating, 61% 182982 B/s431102 bytes written, 0 bytes skipped in 2.800s, speed 157491 B/s
=> load mmc 1 ${loadaddr} tispl.bin
723856 bytes read in 35 ms (19.7 MiB/s)
=> sf update $loadaddr 0x80000 $filesize
device 0 offset 0x80000, size 0xb0b90
   Updating, 37% 189039 B/s   Updating, 73% 184238 B/s723856 bytes written, 0 bytes skipped in 4.396s, speed 168499 B/s
=> load mmc 1 ${loadaddr} u-boot.img
1006404 bytes read in 48 ms (20 MiB/s)
=> sf update $loadaddr 0x280000 $filesize
device 0 offset 0x280000, size 0xf5b44
   Updating, 27% 189305 B/s   Updating, 53% 192082 B/s   Updating, 79% 191557 B/s1006404 bytes written, 0 bytes skipped in 5.616s, speed 183373 B/s
=> md.l 0x43000030 1
43000030: 00000243                               C...
=> 
U-Boot SPL 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:42 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Trying to boot from SPI
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.00.00.004-dirty
NOTICE:  BL31: Built : 21:46:29, Aug 10 2021

U-Boot SPL 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:02 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
Trying to boot from SPI


U-Boot 2021.01-g53e79d0e89 (Aug 10 2021 - 21:47:02 +0000)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev E2
DRAM:  2 GiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000
Hit any key to stop autoboot:  2  0 
=> md.l 0x43000030 1
43000030: 00000273                               s...
=>

Processors

Processors forum

AM6442: SPI boot fails on custom board with SDK 8.xx.