fsl_qspi.c init sequence not working when u-boot configures QSPI for AHB reads

cancel
Showing results for 
Search instead for 
Did you mean: 

fsl_qspi.c init sequence not working when u-boot configures QSPI for AHB reads

405 Views
Contributor II

if u-boot configures QSPI for AHB reads, the M4 must clear the
QUADSPI_BFGENCR register during its init to bring it back to a well
known state.

void QSPI_SoftwareReset(QuadSPI_Type *base)
{
uint32_t i = 0;

/* Reset AHB domain and buffer domian */
base->MCR |= (QuadSPI_MCR_SWRSTHD_MASK | QuadSPI_MCR_SWRSTSD_MASK);
!!!!!!!!!!!!!!!!!!!!!!base->BFGENCR = 0;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

/* Wait several time for the reset to finish, this method came from IC team */
for (i = 0; i < 100U; i++)
{
__NOP();
}

/* Disable QSPI module */
QSPI_Enable(base, false);

/* Clear the reset flags */
base->MCR &= ~(QuadSPI_MCR_SWRSTHD_MASK | QuadSPI_MCR_SWRSTSD_MASK);

/* Enable QSPI module */
QSPI_Enable(base, true);
}
Is this line in attached code snippet missing in official driver, or is there better solution of situation?
Tags (2)
11 Replies

255 Views
Contributor II

Hi !

Just to weight in the discussion. The use case is the following:

  • M4 code is accessing part of the QSPI as a log space.
  • A7 core might be rebooting while M4 is still operational.
  • As u-boot comes up and does some verification on the QSPI, M4 waits before reaccessing the qspi log zone
  • u-boot accesses the QSPI with its own set of QSPI config parameters (reinit qspi)
  • When u-boot is down and A7 stops accessing QSPI, M4 must reset and reinit the QSPI config to its desired config before proceeding.

The current sdk2.8 implementation of the Reset routine in fsl_qspi does not provide insurance of a proper reset state with BFGENCR potentially in a non-default state after u-boot accessed the QSPI. This patch is to ensure this does not happen. It is an issue we have faced when rebooting the A7 side while keeping M4 in operation (only A7 reboot). With the M4 not being able to properly reinitialize and read/write to the qspi afterward.

Note that:

0 Kudos

136 Views
NXP Employee
NXP Employee

Hi quentincabrol,

We would like to know a bit more about the set-up.

Is it a single memory boot or dual memory boot?

How A7 is rebooted? From M4 or A7?

Regards,

Karan Gajjar

0 Kudos

101 Views
Contributor II

Hi Karan,

Sorry I missed your message. This is a dual memory boot. With uboot loading A7 Linux from eMMC and M4 loading its program from a dedicated QSPI.

In term of operation, several situations can occur:

- A7 rebooting alone

- A7 rebooting the whole system from u-boot after a M4 update was downloaded (power reset occurs)

- M4 resetting the system with a POR on wdog0 timeout as a safety measure against freezing code

Kind Regards

0 Kudos

81 Views
NXP Employee
NXP Employee

Hi quentincabrol,

No issues.

Here is how we tried to replicate the issue, we copied the QSPI polling example from the "SDK_2.8.0_EVK-MCIMX7ULP/boards/evkmcimx7ulp/driver_examples/qspi/polling_transfer" and integrated it with the power mode example in the demo apps "SDK_2.8.0_EVK-MCIMX7ULP/boards/evkmcimx7ulp/demo_apps/power_mode_switch".

We have created a separate task for the polling QSPI along with the power mode switch, you can find the source code as well as the binary in the attachment. So the M4 will do the QSPI polling test regularly. We flashed this M4 image in QSPI and Linux(A7) in the SD card and booted the board.

Next, we rebooted A7 using reboot command in A7 itself. However, our observation was that the polling QSPI application was running smoothly in the M4. We rebooted around 3-4 times from A7 and the M4 application was running fine.

Kindly, let us know if we are missing something in the setup here, or if you have a demo application for M4, we will check that on our end with the default Linux image in A7 and will let you know the result.

Regards,

Karan Gajjar

0 Kudos

57 Views
Contributor II

Hi Karan,

I think that the issue is specific to the fact that uboot on A7 reboots does two things in our case to the M4 QSPI:

  • uboot sets QSPI for access from uboot & checks QSPI firmware SHA & signature (secure boot)
  • If SHA doesn't match what the uboot expects, QSPI flash is reflashed with a known firmware stored n eMMC and a system POR ensues.

During the A7 reboot sequence, M4 will not access the qspi and once the reboot is completed the qspi config will be reinitialized by the M4 firmware back to a known state (in theory) for M4 access.

base->BFGENCR = 0;

But the missing BFGENCR register clear means the software reset could be improper. Not sure how best to reproduce that, maybe you would need our uboot lut config for the qspi ? uboot must access the QSPI and read it during reboot for sure.

0 Kudos

137 Views
NXP Employee
NXP Employee
 
0 Kudos

341 Views
NXP TechSupport
NXP TechSupport

Which source code are you talking about? Could you tell me the location of the source code.

What is the version of it?

Thanks.

0 Kudos

330 Views
Contributor II

Hi @jimmychan , as mentioned in  header the issue is in fsl_qspi.c. We observed this issue in sdk2.6, sdk2.7 and sdk2.8(newest one). Currently we need add this one line manually.

 

Solution is showed inside code snippet inside !!!!!!!!!!!!!!!!! ... !!!!!!!!!!!!!!!!

 

it is qspi driver used in our case in imx7ulp

0 Kudos

302 Views
NXP TechSupport
NXP TechSupport

Our expert have a few queries regarding the patch you have mentioned.

===========================

The customer has explicitly written 0 to BFGENCR (Buffer generic configuration register) in the QSPI reset function.

Has the customer faced any issue while resetting his application or the EVK? If yes, can he provide the steps for the same?

Has the customer tried with the sample QSPI driver provided by the NXP?

Can the customer confirm whether the below note is applicable to his scenario?

This note in imx7ULPRM connects to the patch in which the customer has reset the value of SEQID by writing 0.

qspi_bfgencr.png

============================

0 Kudos

279 Views
Contributor II

My colleague is saying that the case was when uboot run before m4. M4 inits QSPI (m4 assume it comes from reset), that value wasnt set to its default;

0 Kudos

264 Views
NXP TechSupport
NXP TechSupport

Below are our additional observations:

  • We checked in u-boot for Linux version 5.4.24-2.1.0, RX Buffer content is read using the AHB Bus registers by default. From the file: drivers/spi/fsl_qspi.c
    /*
    * There are two different ways to read out the data from the flash:
    * the "IP Command Read" and the "AHB Command Read". 
    *
    * 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.)
    *
    * After we set up the registers for the "AHB Command Read", we can use
    * the memcpy to read the data directly. A "missed" access to the buffer
    * causes the controller to clear the buffer, and use the sequence pointed
    * by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
    */

    Also, we checked on u-boot, the register value of RX Buffer Control Register (QuadSPIx_RBCT): 
  • => md.w 0x410a5110 2
    410a5110: 0007 0000

    This indicates RXBRD bit is set to 0: RX Buffer content is read using the AHB Bus registers QSPI_ARDB0 to QSPI_ARDB15

  • We also checked the qspi_polling_transfer.c example from the SDK_2.8.0_EVK-MCIMX7ULP. We modified the example to continuously test and read the RBCT register.
    Added below line in the qspi_polling_transfer.c:
    while (1) 
    { 
    PRINTF("RBCT Reg: 0x%x\n",QSPI_ReadRBCT_Reg(EXAMPLE_QSPI));
    qspi_polling();
    int tmp = 200000000;
    while(tmp--);
    } 

    fsl_qspi.h:
    inline int32_t QSPI_ReadRBCT_Reg(QuadSPI_Type *base){                                                                                                 
            return base->RBCT;
    }
    

    Below is the output on M4 console:
    QSPI example started!
    Erase finished!
    Program data finished!
    Program through QSPI polling succeed!
    RBCT Reg: 0x7
                 Erase finished!
    Program data finished!
    Program through QSPI polling succeed!
    RBCT Reg: 0x7
                 Erase finished!
    Program data finished!
    Program through QSPI polling succeed!
    RBCT Reg: 0x7
                 Erase finished!
    Program data finished!
    Program through QSPI polling succeed!
    RBCT Reg: 0x7
                 Erase finished!
    Program data finished!
    Program through QSPI polling succeed!
    

 

So, if you have any specific scenario or application, do let us know the steps or provide us with the application to test on.

0 Kudos