AM6442: AM6442 QSPI issue

Do you still have the QSPI boot issue?
if yes, will you describe the issue in more details?

Yes, still have this issue.

I found that it will stopped in __memcpy_fromio() . 

static inline
void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t count)
{
while (count && !IS_ALIGNED((unsigned long)from, 8)) {
*(u8 *)to = __raw_readb(from);
from++;
to++;
count--;
}

while (count >= 8) {
*(u64 *)to = __raw_readq(from);
from += 8;
to += 8;
count -= 8;
}

while (count) {
*(u8 *)to = __raw_readb(from);
from++;
to++;
count--;
}
}

The code in uboot is borrowed from kernel. In earlier kernel version until v4.15, these code were:

void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t count)
{
	while (count && (!IS_ALIGNED((unsigned long)from, 8) ||
			 !IS_ALIGNED((unsigned long)to, 8))) {
		*(u8 *)to = __raw_readb(from);
		from++;
		to++;
		count--;
	}

	while (count >= 8) {
		*(u64 *)to = __raw_readq(from);
		from += 8;
		to += 8;
		count -= 8;
	}

	while (count) {
		*(u8 *)to = __raw_readb(from);
		from++;
		to++;
		count--;
	}
}
 If judge both 'from' and 'to' as older kernel does, it won't be stopped, but it will slow down the bootup. That's what I found.


Best Regards
xixiguo

Hi xixiguo,
Thanks for your debug analysis on the issue.

xixiguohx said:

If judge both 'from' and 'to' as older kernel does, it won't be stopped, but it will slow down the bootup. That's what I found.

For the two test cases: 1/. boot not working; 2/. boot working but slow boot-up, can we capture the full boot logs starting from SoC RESET and upload them as attachments.
Best,
-Hong

U-Boot SPL 2021.01-g8e7635763e-dirty (Jan 06 2022 - 09:34:29 +0800)
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed 1
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 : 14:39:59, Aug  9 2021

U-Boot SPL 2021.01-g8e7635763e-dirty (Jan 06 2022 - 09:35:04 +0800)
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed 1
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
Trying to boot from SPI


U-Boot 2021.01-g8e7635763e-dirty (Jan 06 2022 - 09:35:04 +0800)

SoC:   AM64X SR1.0
P3Y KP Board
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed 1
DRAM:  512 MiB
Loading Environment from SPIFlash... cadence_spi spi@fc40000: Can't get reset: -2
jedec_spi_nor flash@0: Software reset enable failed: -524
SF: Detected is25lp032 with page size 256 Bytes, erase size 64 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed 1
Net:   am65_cpsw_nuss_slave ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA00903 cpsw_ver: 0x6BA80903 ale_ver: 0x00294104 Ports:2 mdio_freq:1000000
eth0: ethernet@8000000
Hit any key to stop autoboot:  0 
=> 

U-Boot SPL 2020.01-g2781231a33 (Sep 06 2021 - 01:18:03 +0000)
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x51 failed 1
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
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 : 14:39:59, Aug  9 2021

U-Boot SPL 2021.01 (Sep 16 2021 - 16:51:42 +0800)
EEPROM not available at 80, trying to read at 81
Reading on-board EEPROM at 0x50 failed 1
SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
Trying to boot from SPI

Hi Hong,

Please see the docs. The uboot can not startup log is a little old, I tried different combination of the boot images, so you can see the version is not the same. But even the same version, it still stopped at the same place. So it's the same phenomenon.

Best regards

xixiguo

Hi xixiguo,
I'm not able to reproduce the issue you reported as OSPI boot works on AM64x GP EVM.
I tested OSPI read speed on AM64x GP EVM @u-boot as listed below for your reference.

=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> time sf read $loadaddr 0x0 0x400000
device 0 offset 0x0, size 0x400000
SF: 4194304 bytes @ 0x0 Read: OK

time: 0.019 seconds

- Can we run the similar SPI speed test for your working case on your board?
- Also, it seems from your log that there's 4MiB QSPI on your board. What will you boot the kernel/rootfs from?
BTW, I'll be out of office till next Tue (01/11).
Best,
-Hong

Hi Hong,

=> sf probe
jedec_spi_nor flash@0: Software reset enable failed: -524
SF: Detected is25lp032 with page size 256 Bytes, erase size 64 KiB, total 4 MiB
=> time sf read 0x82000000 0x0 0x400000
device 0 whole chip
SF: 4194304 bytes @ 0x0 Read: OK

time: 1.615 seconds

This is the working case test result. Yes, we use 4 line of QSPI. The kernel is boot from tftp and we use nfs rootfs.

The not working case blocked at u-boot.img booting when stopped in __memcpy_fromio() .

Best Regards

xixiguo

Hi xixiguo,
- Non-working case: no code change in __memcpy_fromio();
- Working case: revert __memcpy_fromio() back to the older version.

I had a closer look at the boot log files you shared, and observed that:
1. R5 SPL (or tiboot3.bin) read from QSPI by on-chip bootrom, and boot is ok for the both cases.
2. A53 SPL read from QSPI by R5 SPL, and boot is ok for the both cases.
3A. A53 u-boot.img read from QSPI by A53 SPL, and boot is ok for the working case;
3B. A53 u-boot.img read from QSPI by A53 SPL locks up for the non-working case;

My understanding from the commit comment on __memcpy_fromio() is to improve performance for arm64 SoC.
git.ti.com/.../io.c

When you reverted __memcpy_fromio() back to the older version, essentially it slows down QSPI read speed, and QSPI boot started working on your board.
It seems to me that QSPI timing needs to be tuned up somehow. Have you contacted QSPI vendor (Macronix) for support?

Best,
-Hong

Hi Hong,

I have not contact QSPI vendor yet. But I have tried slow down the QSPI frequency, it does not work.

Best Regards

xixiguo

Hi xixiguo,
Please contact QSPI vendor for their feedback on timing tuneup on your customer board.
Best,
-Hong