S32G2 / uboot / mt35xu flash nor read issue

[gse31]

Hi,

I have a custom board with S32G2 and mt35xu flash nor.

BootROM reads nor flash correctly.

Uboot is started but fails to read flash jedec id bytes. Uboot version is 2022.04.

It worked with uboot 2020.04.

Read id is 0x96 0x2d 0x8d (expected : 0x2c 0x5b 0x1a).  Almost a 1-bit left shift...

The LUT programmed by uboot is 0x1c06049f (read id command srd 1 bit bus wide).

With a scope, we see the qspi clock at 200MHz.

mt35xu does not seem to work at 200MHz in SDR mode.

How to reduce this frequency, tried in qspi node in the dtsi, in micro_params.c too. Freq is always 200M ?

Did you test uboot with this config (s32g2 with mt35xu) ?

Thanks

[gse31]

Hi,

I previoulsy worked with BSP36 / uboot 2020.04, and the uboot sf worked.

Now integrating BSP38 / uboot 2022.04, and have/had issues with uboot sf.

The qspi frequency is always 200MHz in uboot when modifying the 2 dtsi with the value 133333333.

I set the qspi parameters at offset 0x200 in the FIP image to have 133M, and both the bootROM and the ATF perform QSPI transfers at 133M. U-boot still uses a 200M clock.

I had to modify the uboot fsl qspi driver to make it worked at 200M:

- Force the dqs pad loopback in the QSPI MCR register (DQS_FA_SEL = b10, indicated reserved in the S32G2 RM rev 7, error ?) : the jedec id bytes are then read correctly.

- Then I had an issue with the uboot sf read command / uboot var env reading: the QSPI LUT programmed was 0xfdfd instead of 0x02fd for a 8DTR read sequence, with 40 dummy bytes. By forcing the LUT sequence to 0xfd02 and 20 dummy bytes, it worked.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. We apologize if we are misunderstanding your last comment, but it seems that you were able to resolve the overall issue by the steps you are mentioning, is this correct?

If not, we may have misunderstood the overall comment, for which we apologize.

Please, let us know.

[gse31]

Hi,

The issue is solved by patching the uboot qspi driver.

But we would like to have the ability to lower the qspi frequency.

Are you able to change this qspi frequency on NXP eval board only by modifying the s32cc.dtsi and s32cc-nxp-flash-....dtsi ?

Thanks

[Daniel-Aguirre]

Hi,

Thanks for your feedback. From our side, this has been verified within the internal team. Also, the following information is provided by them:

"

• To lesser the SPI frequency, besides applying patches provided previously to below files, also need to modify the "S32GEN1_QSPI_CLK_FREQ" to targeting frequency in file "../arm-trusted-firmware/2.5-r0/git/include/dt-bindings/clock/s32gen1-clock-freq.h". 
  • Files to apply patch for spi frequency
    • ./tmp/work/s32g274ardb2-fsl-linux/arm-trusted-firmware/2.5-r0/git/fdts/s32cc.dtsi
      ./tmp/work-shared/s32g274ardb2/kernel-source/arch/arm64/boot/dts/freescale/s32cc.dtsi
      ./tmp/work/s32g274ardb2-fsl-linux/arm-trusted-firmware/2.5-r0/git/fdts/s32cc-nxp-flash-macronix.dtsi
      ./tmp/work-shared/s32g274ardb2/kernel-source/arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi

"

Please, let us know.

[gse31 · Accepted solution]

Hi,

It worked (reducing qspi freq to 133M) by setting S32GEN1_QSPI_133MHZ in platform_def.h, in addition to dtsi modifications.

Thanks for your help !

[Daniel-Aguirre]

Hi,

Can you let us know which BSP version are you using for your current development? Since you are using a custom board, we might not be able to reproduce the situation under the current channel, for which we apologize.

We can recommend either contacting your local NXP representative or opening a ticket under the NXP online services. Since this might require specific patches to be shared, a private channel is desired. Again, we apologize for any inconvenience.

As for reducing the frequency, we see the below information is provided by the internal team:

"

arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi | 2 +-
arch/arm64/boot/dts/freescale/s32cc.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi b/arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi
index 096a8f62079a..351b835a20e3 100644
--- a/arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32cc-nxp-flash-macronix.dtsi
@@ -6,7 +6,7 @@
&qspi {
macronix_memory: mx25uw51245g@0 {
compatible = "jedec,spi-nor";
- spi-max-frequency = <200000000>;
+ spi-max-frequency = <133333333>;
spi-tx-bus-width = <8>;
spi-rx-bus-width = <8>;
reg = <0>;
diff --git a/arch/arm64/boot/dts/freescale/s32cc.dtsi b/arch/arm64/boot/dts/freescale/s32cc.dtsi
index afca4a352c69..c0983795bf8c 100644
--- a/arch/arm64/boot/dts/freescale/s32cc.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32cc.dtsi
@@ -338,7 +338,7 @@ qspi: spi@40134000 {
clock-names = "qspi_en", "qspi";
clocks = <&clks S32CC_SCMI_CLK_QSPI_FLASH1X>,
<&clks S32CC_SCMI_CLK_QSPI_FLASH1X>;
- spi-max-frequency = <200000000>;
+ spi-max-frequency = <133333333>;
spi-num-chipselects = <2>;
status = "disabled";
};
--
2.25.1

"

This information is provided under BSP36.0, for which there could be differences depending on your specific BSP version. Also, this patch is applied for the available memory under the NXP reference boards.

Please, let us know.