SPI NOR w25q128 "flash operation timed out"

SPI NOR w25q128 "flash operation timed out"

[Klotz, Oliver]

Hello,

I am using an am335x based SOM with SPI NOR flash.
Recently the SOM vendor replaced Micron n25q128a13 with Winbond w25q128.

Winbond works fine with barebox-2016.07.0, but fails with barebox-2023.01.0, barebox-2022.09.0, barebox-2021.07.0.

Although the device is properly detected as “m25p80 m25p80@00: w25q128 (16384 Kbytes)” – INFO(0xef4018).
erase and mw commands end in "flash operation timed out".

I tried w/wo CONFIG_MTD_SPI_NOR_USE_4K_SECTORS and with 24/48MHz SPI clock.

I have added some trace messages for read_sr() and run “erase /dev/m25p0.bareboxenv” (partition size = 128 Kbytes, sector size = 64 Kbytes)

read_sr() returns 0x00 0x03 0x03 0x03 0x03 0x03 0x03 and then it is stuck to 0xff and this is causing the timeout.

When running the same binary on the Micron-SOM then I get 0x00, a bunch of 0x03, 0x00, a bunch of 0x03 and finally 0x00 as expected for erasing 2 sectors.


Is anyone facing similar issue with w25q128?

Any idea what might be the problem here?


Thanks and best Regards

Oliver Klotz


Kiepe Electric GmbH
Firmensitz:  Kiepe-Platz 1, D-40599 Düsseldorf
Geschäftsführer: Alexander Ketterl
Registergericht: Düsseldorf HRB 34306
Zertifiziert: DIN EN ISO 9001:2015

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: SPI NOR w25q128 "flash operation timed out"

[Ahmad Fatoum]

Hello Oliver,

On 17.02.23 09:22, Klotz, Oliver wrote:
> Hello,
> 
> I am using an am335x based SOM with SPI NOR flash.
> Recently the SOM vendor replaced Micron n25q128a13 with Winbond w25q128.
> 
> Winbond works fine with barebox-2016.07.0, but fails with barebox-2023.01.0, barebox-2022.09.0, barebox-2021.07.0.

Can you use git bisect to narrow down the commit that caused the regression?

Cheers,
Ahmad

> 
> Although the device is properly detected as “m25p80 m25p80@00: w25q128 (16384 Kbytes)” – INFO(0xef4018).
> erase and mw commands end in "flash operation timed out".
> 
> I tried w/wo CONFIG_MTD_SPI_NOR_USE_4K_SECTORS and with 24/48MHz SPI clock.
> 
> I have added some trace messages for read_sr() and run “erase /dev/m25p0.bareboxenv” (partition size = 128 Kbytes, sector size = 64 Kbytes)
> 
> read_sr() returns 0x00 0x03 0x03 0x03 0x03 0x03 0x03 and then it is stuck to 0xff and this is causing the timeout.
> 
> When running the same binary on the Micron-SOM then I get 0x00, a bunch of 0x03, 0x00, a bunch of 0x03 and finally 0x00 as expected for erasing 2 sectors.
> 
> 
> Is anyone facing similar issue with w25q128?
> 
> Any idea what might be the problem here?
> 
> 
> Thanks and best Regards
> 
> Oliver Klotz
> 
> 
> Kiepe Electric GmbH
> Firmensitz:  Kiepe-Platz 1, D-40599 Düsseldorf
> Geschäftsführer: Alexander Ketterl
> Registergericht: Düsseldorf HRB 34306
> Zertifiziert: DIN EN ISO 9001:2015
> 
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

RE: SPI NOR w25q128 "flash operation timed out"

[Klotz, Oliver]

Hello Ahmad,

while doing the bisecting it turned out, that the issue with w25q128 is not related to a specific Barebox version
but to 2nd chip select of the SPI bus.

In older products we are using Barebox-2016.07.0 and there is just the SPI NOR as single SPI slave (spi0_cs0).
In the pinmux only spi0_cs0 is multiplexed. And this binary works fine on SOM with n25q128a13 as well as w25q128.

In newer products we are using Barebox-2021.07.0 and there we have a TPM (spi0_cs1) as 2nd SPI slave.
Since Barebox doesn´t support TPM I have removed the TPM slave node from spi0, but sp0_cs1 is still pinmuxed.
This is just because I reuse pinmux section from the Linux dts.

Whenever sp0_cs1 is pinmuxed I observe timeouts with w25q128.
Strange thing here is that exactly the same binary works without issues on SOM with n25q128a13.

Also in the Linux dts the spi0_cs1 doesn´t cause any issue and TPM as well as w25q128 are working perfectly fine.

So removing the spi0_cs1 from the Barebox dts fixes my issue - please refer to dts below.

Although I have a working solution I would appreciate your thoughts on this.

Best regards,
Oliver


spi0_pins_default: spi0_pins_default {
        pinctrl-single,pins = <
                AM33XX_IOPAD(0x950, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (A17) spi0_sclk.spi0_sclk */
                AM33XX_IOPAD(0x954, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (B17) spi0_d0.spi0_d0 */
                AM33XX_IOPAD(0x958, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (B16) spi0_d1.spi0_d1 */
                AM33XX_IOPAD(0x95c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (A16) spi0_cs0.spi0_cs0 */
#if 0
                /* Do not mux spi0_cs1 which is for TPM, but causes timeouts to Winbond w25q128 SPI flash. */
                AM33XX_IOPAD(0x960, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (C15) spi0_cs1.spi0_cs1 */
#endif
        >;
};

&spi0 {
        pinctrl-names = "default";
        pinctrl-0 = <&spi0_pins_default>;
        status = "okay";

        flash: m25p80@0 {
                compatible = "jedec,spi-nor";
                reg = <0>; /* CS0 */
                spi-max-frequency = <48000000>;
                m25p,fast-read;
                #address-cells = <1>;
                #size-cells = <1>;

                partition@0 {
                        label = "xload";
                        reg = <0x0 0x20000>;
                };
                /* and some more partitions */
        };
};

-----Original Message-----
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
Sent: Friday, February 17, 2023 9:59 AM
To: Klotz, Oliver <Oliver.Klotz@knorr-bremse.com>; barebox@lists.infradead.org
Subject: Re: SPI NOR w25q128 "flash operation timed out"

Hello Oliver,

On 17.02.23 09:22, Klotz, Oliver wrote:
> Hello,
>
> I am using an am335x based SOM with SPI NOR flash.
> Recently the SOM vendor replaced Micron n25q128a13 with Winbond w25q128.
>
> Winbond works fine with barebox-2016.07.0, but fails with barebox-2023.01.0, barebox-2022.09.0, barebox-2021.07.0.

Can you use git bisect to narrow down the commit that caused the regression?

Cheers,
Ahmad

>
> Although the device is properly detected as "m25p80 m25p80@00: w25q128 (16384 Kbytes)" - INFO(0xef4018).
> erase and mw commands end in "flash operation timed out".
>
> I tried w/wo CONFIG_MTD_SPI_NOR_USE_4K_SECTORS and with 24/48MHz SPI clock.
>
> I have added some trace messages for read_sr() and run "erase /dev/m25p0.bareboxenv" (partition size = 128 Kbytes, sector size = 64 Kbytes)
>
> read_sr() returns 0x00 0x03 0x03 0x03 0x03 0x03 0x03 and then it is stuck to 0xff and this is causing the timeout.
>
> When running the same binary on the Micron-SOM then I get 0x00, a bunch of 0x03, 0x00, a bunch of 0x03 and finally 0x00 as expected for erasing 2 sectors.
>
>
> Is anyone facing similar issue with w25q128?
>
> Any idea what might be the problem here?
>
>
> Thanks and best Regards
>
> Oliver Klotz
>
>
> Kiepe Electric GmbH
> Firmensitz:  Kiepe-Platz 1, D-40599 Düsseldorf
> Geschäftsführer: Alexander Ketterl
> Registergericht: Düsseldorf HRB 34306
> Zertifiziert: DIN EN ISO 9001:2015
>
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2F&data=05%7C01%7Coliver.klotz%40knorr-bremse.com%7Cc8d8d8b229a14cae344a08db10c53191%7C66f6821e0a304a068b8b901bbfd2bc60%7C0%7C0%7C638122211346610727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u%2BOuohpHoyIh%2Ba4E4KHfFVvzsE3oPDtzhDWG80hB31s%3D&reserved=0  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



Kiepe Electric GmbH
Firmensitz:  Kiepe-Platz 1, D-40599 Düsseldorf
Geschäftsführer: Alexander Ketterl
Registergericht: Düsseldorf HRB 34306
Zertifiziert: DIN EN ISO 9001:2015

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

Re: SPI NOR w25q128 "flash operation timed out"

[Alexander Shiyan]

Hello.

чт, 9 мар. 2023 г. в 20:39, Klotz, Oliver <Oliver.Klotz@knorr-bremse.com>:
>
> Hello Ahmad,
>
> while doing the bisecting it turned out, that the issue with w25q128 is not related to a specific Barebox version
> but to 2nd chip select of the SPI bus.
>
> In older products we are using Barebox-2016.07.0 and there is just the SPI NOR as single SPI slave (spi0_cs0).
> In the pinmux only spi0_cs0 is multiplexed. And this binary works fine on SOM with n25q128a13 as well as w25q128.
>
> In newer products we are using Barebox-2021.07.0 and there we have a TPM (spi0_cs1) as 2nd SPI slave.
> Since Barebox doesn´t support TPM I have removed the TPM slave node from spi0, but sp0_cs1 is still pinmuxed.
> This is just because I reuse pinmux section from the Linux dts.
>
> Whenever sp0_cs1 is pinmuxed I observe timeouts with w25q128.
> Strange thing here is that exactly the same binary works without issues on SOM with n25q128a13.
>
> Also in the Linux dts the spi0_cs1 doesn´t cause any issue and TPM as well as w25q128 are working perfectly fine.
>
> So removing the spi0_cs1 from the Barebox dts fixes my issue - please refer to dts below.
>
> Although I have a working solution I would appreciate your thoughts on this.
>
> Best regards,
> Oliver
>
>
> spi0_pins_default: spi0_pins_default {
>         pinctrl-single,pins = <
>                 AM33XX_IOPAD(0x950, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (A17) spi0_sclk.spi0_sclk */
>                 AM33XX_IOPAD(0x954, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (B17) spi0_d0.spi0_d0 */
>                 AM33XX_IOPAD(0x958, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (B16) spi0_d1.spi0_d1 */
>                 AM33XX_IOPAD(0x95c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (A16) spi0_cs0.spi0_cs0 */
> #if 0
>                 /* Do not mux spi0_cs1 which is for TPM, but causes timeouts to Winbond w25q128 SPI flash. */
>                 AM33XX_IOPAD(0x960, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (C15) spi0_cs1.spi0_cs1 */
> #endif
>         >;
> };
...

A click on the SCLK on the chipselect switch may have an effect.
Try this:
AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE0)
AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE0)
AM33XX_IOPAD(0x958, PIN_INPUT | MUX_MODE0)
AM33XX_IOPAD(0x95c, PIN_OUTPUT_PULLUP | MUX_MODE0)