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

204 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)
6 Replies

54 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

140 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

129 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

101 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

78 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

63 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