LS1043 QSPI flash and AHB

[jiafang]

Hi everyone

We are trying to use the QSPI flash on LS1043 board. Our kernel version is 5.2, flash is mx66u1g45g.

We found that when we get the flash data which size is more then 0x80, then the data will be wrong.

Correct:

00000000 : 31 31 20 30 31 3A 34 32 30 30 30 30 30 30 30 30

...

Wrong:

00000000 : 30 30 30 30 30 30 30 30 49 50 4C 2D 52 4F 4D 33

It seems like the first 8 bytes is lost from the read result.

We found that the code will try to access the AHB to get the data.

1) Is there similar issue as in https://source.denx.de/u-boot/u-boot/-/commit/def88bce094e95939abf1e5d02a9b413b3627f6f on LS1043 ?

2) From ls1043 RM:

IP Command Read: For reading flash data into the RX Buffer the user must
provide the correct sequence ID in the QuadSPI_IPCR[SEQID] register. The
sequence ID points to a sequence in the LUT. It is the responsibility of the
software to ensure that a correct read sequence is programmed in the LUT in
accordance with the serial flash device connected on board.

How do we know the read sequence is correct programmed in the LUT ?

The correct read sequence should be like what seq ? Do you have some examples ?

[jiafang]

Thanks for your reply.

Yes, it is on kernel, not uboot

Which registers need to be dumped ?

We use mtd_debug() to read the flash data, it finally calls fsl_qspi_exec_op(). From where we can know it is IP read or AHB read ? 

[yipingwang]

Can you let me know the details about the issue? I assume that the issue happens under Linux kernel 5.2, not on uboot, is that correct?
Can you dump the QSPI registers and all the data for 128 bytes and 160 bytes read?
A1, I do not think that we have a similar issue on LS1043a. At least it is not limited to 128 Bytes. It limits to the AHB buffer size to 1 KB.
A2. Do you use IP read or AHB read? Yes, it is the software's responsibility to ensure correct read sequence. The qSPI controller does not know or care about the read sequence. The read sequence is based on what is connected to the qSPI bus. The read/write sequences come from the qSPI slave device. The qSPI controller only follow what are in the LUT.
The section Serial Flash Devices in the LS1043ARM (30.9 in rev 5 ) has several Example Sequences.

[jiafang]

Hi
We add some debug info, as following:

Could you help to check if the reg and lut value is normal ?

QUADSPI_BFGENCR is 0xf000
QUADSPI_SFAR is 0x40000000
lutval[0] is 0x10000413 for 0x10b80400 (base + QUADSPI_LUT_REG(0))
lutval[1] is 0x10001010 for 0x10b80404
lutval[2] is 0x1c001008 for 0x10b80408
lutval[3] is 0x0 for 0x10b8040c

read from 100008 len is 0x80
[2023-01-12 13:54:12.400] ahb addr is 0x13800008, start is 0x100008, memmap_start is 0x100008, len is 128
[2023-01-12 13:54:12.409] 00000000 : 30 30 30 30 30 30 30 30 49 50 4C 2D 52 4F 4D 33 : 00000000IPL-ROM3
[2023-01-12 13:54:12.418] 00000010 : 33 36 2E 30 30 2E 30 30 00 00 00 00 00 00 00 00 : 36.00.00........
[2023-01-12 13:54:12.418] 00000020 : 30 30 30 30 30 30 30 30 E7 DC 1B 5D 00 3F FF C0 : 00000000...].?..
[2023-01-12 13:54:12.427] 00000030 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:12.439] 00000040 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:12.444] 00000050 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:12.444] 00000060 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:12.456] 00000070 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................

read from 100008 len is 0xa0
[2023-01-12 13:54:18.923] ahb addr is 0x13800008, start is 0x100008, memmap_start is 0x100008, len is 160
[2023-01-12 13:54:18.932] 00000000 : 30 30 30 30 30 30 30 30 49 50 4C 2D 52 4F 4D 33 : 00000000IPL-ROM3
[2023-01-12 13:54:18.932] 00000010 : 33 36 2E 30 30 2E 30 30 00 00 00 00 00 00 00 00 : 36.00.00........
[2023-01-12 13:54:18.942] 00000020 : 30 30 30 30 30 30 30 30 E7 DC 1B 5D 00 3F FF C0 : 00000000...].?..
[2023-01-12 13:54:18.951] 00000030 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.960] 00000040 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.960] 00000050 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.969] 00000060 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.978] 00000070 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.987] 00000080 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................
[2023-01-12 13:54:18.987] 00000090 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF : ................

Note:
After the patch, the reg value will be changed as:
QUADSPI_BFGENCR is 0xe000
QUADSPI_SFAR is 0x40100008 (0x40000000 + 100008)
lutval[0] is 0x8200413 for 0x10b80400 (base + QUADSPI_LUT_REG(0))
lutval[1] is 0x1c00 for 0x10b80404
lutval[2] is 0x0 for 0x10b80408
lutval[3] is 0x0 for 0x10b8040c

lutval[0] is 0x8200413 for 0x10b803f0 (base + QUADSPI_AHB_LUT_REG(0))
lutval[1] is 0x1c00 for 0x10b803f4
lutval[2] is 0x0 for 0x10b803f8
lutval[3] is 0x0 for 0x10b803fc

[yipingwang]

Can you let me know what patch? Is the issue get resolved after the patch?

[jiafang]

This patch: https://source.denx.de/u-boot/u-boot/-/commit/def88bce094e95939abf1e5d02a9b413b3627f6f
Could you help to check if the lut value is normal before and after the patch ?

[yipingwang]

One more question, do you use our LSDK release? if you do, which version do you use?

[jiafang]

Yes, lsdk-20.04

[yipingwang]

Just want to confirm whether the issue is resolved after the patch.

[jiafang]

Yes we backported to kernel, made some changes to match the kernel code.
We didn't do full test, but at least we can successfully get the 0x80 and 0xa0.