Regression notification - vybrid vf610 QUADSPI - BK4 board

imx Lukasz Majewski 3 participants 8 messages Jul 24, 2019 – Jul 30, 2019

Subsystems (2)

Device tree bindings Memory technology devices (MTD)

lore

Share & tools

lore

Lukasz Majewski

author

2019-07-24 22:11 UTC #0 lore raw

Dear All,

I'd like to report that after moving the fsl-quadspi.c driver from ./drivers/mtd to ./drivers/spi (around 5.1-rc1) [1] the Vybrid's QUADSPI (even with single SPI-NOR memory connected) is not working anymore (the chip ID read is FF FF FF).

This wouldn't be a problem per-se, but not all necessary code was moved
- especially for vybrid which has issues with some HW bugs [2]:

--------------->8----------------
* The IC guy suggests we use the "AHB Command Read" which is faster
* then the "IP Command Read". (What's more is that there is a bug in
* the "IP Command Read" in the Vybrid.)
---------------8<----------------

I've explicitly asked NXP support for this HW issue [3] - but till now there was no reply.

The official linux-imx (from meta-freescale) seems not to support vybrid (vf610) anymore - and the newest available now kernel is 4.19 (with the old fsl-quadspi.c driver available).

Hence the question - has anybody noticed this issue and (maybe) is working on it?

My quick-hack is to revert the changes from [1] and apply some "fixes" (which causes this driver to work on Vybrid) on the old driver [4].

Maybe somebody from NXP ([email protected] ?) can ask HW guys what is the exact problem for Vybrid's QUADSPI controller, so it can be fixed properly in the new kernel?
It would be great is somebody from Linux/HW team could reply to the original post [3].

Thanks in advance for _any_ help.

Note:

[1] - SHA1 IDs for the commits:

84d043185dbe0d1b4f6db575bd91c834d37e2f78
80261459804507a349daf754d6e5d835bb8578ae
78df30808961cd32f0517c7469886386b0680852
50f1242c674226dd866949f24043f5a1076ee242
fcf85e5c2ac0e57430f065c77407e33c7b036a9d

[2] -
https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671

[3] - https://community.nxp.com/thread/485139

[4] -
https://github.com/lmajewski/y2038_kernel/commits/v5.2-vybrid-old-quadspi

Best regards,

Lukasz Majewski

DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [email protected]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Fabio Estevam

2019-07-29 19:10 UTC #1 lore raw

Hi Lukasz,

Quoted 20 lines · Lukasz Majewski

Dear All,
I'd like to report that after moving the fsl-quadspi.c driver from ./drivers/mtd to ./drivers/spi (around 5.1-rc1) [1] the Vybrid's QUADSPI (even with single SPI-NOR memory connected) is not working anymore (the chip ID read is FF FF FF).
This wouldn't be a problem per-se, but not all necessary code was moved
- especially for vybrid which has issues with some HW bugs [2]:
--------------->8----------------
* The IC guy suggests we use the "AHB Command Read" which is faster
* then the "IP Command Read". (What's more is that there is a bug in
* the "IP Command Read" in the Vybrid.)
---------------8<----------------
I've explicitly asked NXP support for this HW issue [3] - but till now there was no reply.

Quoted 8 lines

The official linux-imx (from meta-freescale) seems not to support vybrid (vf610) anymore - and the newest available now kernel is 4.19 (with the old fsl-quadspi.c driver available).
Hence the question - has anybody noticed this issue and (maybe) is working on it?

I don't have access to a Vybrid board, but I kindly got the confirmation from Andrey on Cc that QSPI is working fine on his Vybrid based board running linux-next.

Regards,

Fabio Estevam

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Lukasz Majewski

author

2019-07-29 20:43 UTC #2 lore raw

Hi Fabio,

Quoted 31 lines

Hi Lukasz,
Quoted 28 lines · Lukasz Majewski
Dear All,
I'd like to report that after moving the fsl-quadspi.c driver from ./drivers/mtd to ./drivers/spi (around 5.1-rc1) [1] the Vybrid's QUADSPI (even with single SPI-NOR memory connected) is not working anymore (the chip ID read is FF FF FF).
This wouldn't be a problem per-se, but not all necessary code was moved
- especially for vybrid which has issues with some HW bugs [2]:
--------------->8----------------
* The IC guy suggests we use the "AHB Command Read" which is faster
* then the "IP Command Read". (What's more is that there is a bug
in
* the "IP Command Read" in the Vybrid.)
---------------8<----------------
I've explicitly asked NXP support for this HW issue [3] - but till now there was no reply.
The official linux-imx (from meta-freescale) seems not to support vybrid (vf610) anymore - and the newest available now kernel is 4.19 (with the old fsl-quadspi.c driver available).

Quoted 7 lines

Quoted 2 lines
Hence the question - has anybody noticed this issue and (maybe) is working on it?
I don't have access to a Vybrid board, but I kindly got the confirmation from Andrey on Cc that QSPI is working fine on his Vybrid based board running linux-next.

Thank you for your reply, Fabio.

Andrey , could you share your setup info? How your memories are connected?

Would it be possible to share your dts files for linux-next?

I did a bit more debugging and the old driver (before conversion) on my setup breaks when I try to erase/write/read 256+ bytes (with dd's block size -> bs = 1).

Could you check if erase, write and read of

dd if=/dev/urandom of=/dev/mtd7 bs=1 count=256

works as expected?

Writing larger chunks (with bs=64) works as expected.

Quoted 3 lines

Regards,
Fabio Estevam

Best regards,

Lukasz Majewski

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Fabio Estevam

2019-07-29 21:17 UTC #3 lore raw

Hi Lukasz,

Quoted 1 line · Lukasz Majewski

Thank you for your reply, Fabio.

I assume you are using arch/arm/boot/dts/vf610-bk4.dts

In this file I see that you only define the DATA0 and DATA1 pins for QSPI0_B:

VF610_PAD_PTD11__QSPI0_B_DATA1 0x397f
VF610_PAD_PTD12__QSPI0_B_DATA0 0x397f

Don't you also need to define DATA2 and DATA3?

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Lukasz Majewski

author

2019-07-29 21:54 UTC #4 lore raw

Hi Fabio,

Quoted 8 lines

Hi Lukasz,
Quoted 1 line · Lukasz Majewski
Thank you for your reply, Fabio.
I assume you are using arch/arm/boot/dts/vf610-bk4.dts

Quoted 8 lines

In this file I see that you only define the DATA0 and DATA1 pins for QSPI0_B:
VF610_PAD_PTD11__QSPI0_B_DATA1 0x397f
VF610_PAD_PTD12__QSPI0_B_DATA0 0x397f
Don't you also need to define DATA2 and DATA3?

You got me :-) [1]

The DATA2 and DATA3 (for QSPI0_B "lane") are used for other purposes - this is how the PCB was designed.

At best it is possible to have both memories working with double SPI configuration or single (QSPI0_A with quad SPI [2]).

(And hence it is why I've asked Andrey for sharing his DTS files).

Quoted 3 lines

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Note:

[1] -
https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/vf610-bk4.dts#L235

[2] -
https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/vf610-bk4.dts#L491

Best regards,

Lukasz Majewski

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Fabio Estevam

2019-07-30 03:49 UTC #5 lore raw

Hi Lukasz,

Quoted 2 lines · Lukasz Majewski

At best it is possible to have both memories working with double SPI configuration or single (QSPI0_A with quad SPI [2]).

But according to Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt if you use one chip select for bus A and one chip select for bus B, then you should have your dts changed like this:

arch/arm/boot/dts/vf610-bk4.dts +2 -2

index 3fa0cbe456db..0f3870d3b099 100644
@@ -246,13 +246,13 @@
                reg = <0>;
        };
 
-       n25q128a13_2: flash@1 {
+       n25q128a13_2: flash@2 {
                compatible = "n25q128a13", "jedec,spi-nor";
                #address-cells = <1>;
                #size-cells = <1>;
                spi-max-frequency = <66000000>;
                spi-rx-bus-width = <2>;
-               reg = <1>;
+               reg = <2>;
        };
 };

From the dt-bindings:

"Required SPI slave node properties:
- reg: There are two buses (A and B) with two chip selects each.
This encodes to which bus and CS the flash is connected:
<0>: Bus A, CS 0
<1>: Bus A, CS 1
<2>: Bus B, CS 0
<3>: Bus B, CS 1"

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Lukasz Majewski

author

2019-07-30 15:15 UTC #6 lore raw

Hi Fabio,

Quoted 21 lines

Hi Lukasz,
Quoted 2 lines · Lukasz Majewski
At best it is possible to have both memories working with double SPI configuration or single (QSPI0_A with quad SPI [2]).
But according to Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt if you use one chip select for bus A and one chip select for bus B, then you should have your dts changed like this:
(quoted diff) +0 -0
b/arch/arm/boot/dts/vf610-bk4.dts index 3fa0cbe456db..0f3870d3b099 100644 --- a/arch/arm/boot/dts/vf610-bk4.dts
+++ b/arch/arm/boot/dts/vf610-bk4.dts
arch/arm/boot/dts/vf610-bk4.dts +0 -1
@@ -246,13 +246,13 @@
                reg = <0>;
        };
 
-       n25q128a13_2: flash@1 {

arch/arm/boot/dts/vf610-bk4.dts line 257

Quoted 10 lines

arch/arm/boot/dts/vf610-bk4.dts +2 -1

+       n25q128a13_2: flash@2 {
                compatible = "n25q128a13", "jedec,spi-nor";
                #address-cells = <1>;
                #size-cells = <1>;
                spi-max-frequency = <66000000>;
                spi-rx-bus-width = <2>;
-               reg = <1>;
+               reg = <2>;
        };
 };

That was the exact issue it seems. I've tested the 5.2. kernel with this test [1] and it works reliably now.

Apparently those were leftovers from some old, in-house development.

Anyway thanks for help :-)

Quoted 10 lines

From the dt-bindings:
"Required SPI slave node properties:
- reg: There are two buses (A and B) with two chip selects each.
This encodes to which bus and CS the flash is connected:
<0>: Bus A, CS 0
<1>: Bus A, CS 1
<2>: Bus B, CS 0
<3>: Bus B, CS 1"

Note:

[1] -
https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_nor_quadspi_test.sh

Best regards,

Lukasz Majewski

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Andrey Smirnov

2019-07-30 03:07 UTC #7 lore raw

In reply to Lukasz Majewski

Quoted 42 lines · Lukasz Majewski

Hi Fabio,
Quoted 31 lines
Hi Lukasz,
Quoted 28 lines · Lukasz Majewski
Dear All,
I'd like to report that after moving the fsl-quadspi.c driver from ./drivers/mtd to ./drivers/spi (around 5.1-rc1) [1] the Vybrid's QUADSPI (even with single SPI-NOR memory connected) is not working anymore (the chip ID read is FF FF FF).
This wouldn't be a problem per-se, but not all necessary code was moved
- especially for vybrid which has issues with some HW bugs [2]:
--------------->8----------------
* The IC guy suggests we use the "AHB Command Read" which is faster
* then the "IP Command Read". (What's more is that there is a bug
in
* the "IP Command Read" in the Vybrid.)
---------------8<----------------
I've explicitly asked NXP support for this HW issue [3] - but till now there was no reply.
The official linux-imx (from meta-freescale) seems not to support vybrid (vf610) anymore - and the newest available now kernel is 4.19 (with the old fsl-quadspi.c driver available).
Quoted 7 lines
Quoted 2 lines
Hence the question - has anybody noticed this issue and (maybe) is working on it?
I don't have access to a Vybrid board, but I kindly got the confirmation from Andrey on Cc that QSPI is working fine on his Vybrid based board running linux-next.

Quoted 5 lines

Thank you for your reply, Fabio.
Andrey , could you share your setup info? How your memories are connected?

I did all my testing on ZII VF610 devboard rev C. The board has two SPI-NOR chips connected to 4-bit QSPI_A and 4-bit QSPI_B. See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/vf610-zii-dev.dtsi?h=v5.3-rc2#n180

Quoted 2 lines

Would it be possible to share your dts files for linux-next?

I don't have a special DTS file I am using. The one currently available upstream is what I am using:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts

Quoted 10 lines

I did a bit more debugging and the old driver (before conversion) on my setup breaks when I try to erase/write/read 256+ bytes (with dd's block size -> bs = 1).
Could you check if erase, write and read of
dd if=/dev/urandom of=/dev/mtd7 bs=1 count=256
works as expected?

# flash_erase /dev/mtd0 0 1024
Erasing 64 Kibyte @ 3ff0000 -- 100 % complete
# dd if=/dev/urandom of=blob.bin bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.0360427 s, 28.4 kB/s
# md5sum blob.bin
5064a3852988ce75c60e9bc867f62230  blob.bin
# dd if=blob.bin of=/dev/mtd0 bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.269917 s, 3.8 kB/s
# dd if=/dev/mtd0 bs=1 count=1024 | md5sum
5064a3852988ce75c60e9bc867f62230  -
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.182514 s, 5.6 kB/s

AFAICT works as expected.

Thanks,
Andrey Smirnov

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/