This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi experts,
From TRM and SDK, I noticed that each read-access to external QSPI-Flash is in byte unit? Is there possibility to read external Flash device in 16 or 32 or even 64-bit?
In sysconfig, we can modify the word length for one QSPI transaction, but I am not sure the compatibility between this configuration with Bootloader driver as shown above. Please give some help.
Thanks
Will
Hi Will,
You are correct. According to our TRM, you should be able to program the length of the words transferred during communication anywhere from 1 to 128 bits. You can do this easily by modifying your setting in SysConfig, as you have noticed.
However, this driver modification is independent from the bootloader operation that the ROM performs on the boot sequence as it only affects the QSPI application driver. You can safely modify this values without affecting the bootloader operation.
Best,
Daniel
Hi Daniel,
Thanks for your input. Let customer to increase the length of the word to 16/32/64-bit, but the bootloader driver will prompt that 'ERROR: Board_flashOpen: 98: FLASH open failed for instance 0'.
Best Regards,
Will
Hi Daniel,
The QSPI Flash generally has a mode called fast-read mode. And from TRM, our QSPI IP has this feature. But I want to know If this mode supported by our bootloader+QSPI driver? I don't see any related configuration in SysConfig window.
Best Regards,
Will
Hi Will,
But I want to know If this mode supported by our bootloader+QSPI driver
0x6B Fast Read command is supported by our bootloader. This is the mode that should be enabled by default and you should not have to modify anything for correct operation.
but the bootloader driver will prompt that 'ERROR: Board_flashOpen: 98: FLASH open failed for instance 0'.
As for this question, was the driver working before on 8 bit operation? what flash device is your customer using? Normally this error pops up when the support for the flash has not been added to our drivers, so I'd like to verify if this is the case.
Best,
Daniel
Hi Daniel,
As for this question, was the driver working before on 8 bit operation? what flash device is your customer using?
I am using AM2634-CC EVM board. And 8-bit operation is ok. Please verify this, thanks a lot.
Best Regards,
Will
Thanks Will,
I will take a look and get back to you after running some tests. I will get back to you by tomorrow Friday.
Best,
Daniel
Hi Daniel,
I wrote a program to test the 32-bit access to external Flash as below:
// QSPI configuration CSL_QspiRegs * qspi_regs_struct = (CSL_QspiRegs *)CSL_QSPI0_U_BASE ; qspi_regs_struct->SPI_SWITCH_REG = CSL_QSPI_SPI_SWITCH_REG_MMPT_S_SEL_CFG_PORT ; // configure SPI_CORE // SPI Clock generator qspi_regs_struct->SPI_CLOCK_CNTRL_REG = (qspi_regs_struct->SPI_CLOCK_CNTRL_REG & (~CSL_QSPI_SPI_CLOCK_CNTRL_REG_DCLK_DIV_MASK)) | 0U ; // 80 MHz qspi_regs_struct->SPI_CLOCK_CNTRL_REG |= CSL_QSPI_SPI_CLOCK_CNTRL_REG_CLKEN_MASK ; // SPI Clock polarity and phase modes 3 (or 0) qspi_regs_struct->SPI_DC_REG = qspi_regs_struct->SPI_DC_REG | CSL_QSPI_SPI_DC_REG_CKP0_MASK | CSL_QSPI_SPI_DC_REG_CKPH0_MASK ; // SFI configuration qspi_regs_struct->SPI_SETUP0_REG = (CSL_QSPI_SPI_SETUP0_REG_RCMD_MASK & 0x6CU) | (0x3U << CSL_QSPI_SPI_SETUP0_REG_NUM_A_BYTES_SHIFT) | (0x1U << CSL_QSPI_SPI_SETUP0_REG_NUM_D_BYTES_SHIFT) | (CSL_QSPI_SPI_SETUP0_REG_READ_TYPE_QUAD_READ << CSL_QSPI_SPI_SETUP0_REG_READ_TYPE_SHIFT) | (0x8U << CSL_QSPI_SPI_SETUP0_REG_NUM_D_BITS_SHIFT ) ; qspi_regs_struct->SPI_SWITCH_REG = CSL_QSPI_SPI_SWITCH_REG_MMPT_S_SEL_MM_PORT ; readFlash = *((uint32_t *)0x60000000) ;
And from the waveform of QSPI interface, it can directly read a 32-bit word for one transaction. And I think 32-bit read will help speed up the SBL boot time. MCU+ SDK is copying data in byte, which is slower. I am not sure what is the width of the DMA case, please help confirm if it is 8-bit width too.
Could BU help modify the driver to support 32-bit or 16-bit access to external Flash device? It will help my customer to meet their OEM's requirement. Thanks a lot.
Best Regards,
Will
Hi Daniel,
I have modified the SDK <driver/qspi/v0/qspi.c> as follow:
static int32_t QSPI_spiMemMapRead(QSPI_Handle handle) { /* Destination address */ uint32_t *pDst = NULL; /* Source address */ uint32_t *pSrc = NULL; /* Transaction length */ uint32_t count; /* Memory mapped command */ uint32_t mmapReadCmd; uintptr_t temp_addr; uintptr_t offset; int32_t status = SystemP_SUCCESS; uint32_t dummyBytes, dummyBits; if(handle != NULL) { QSPI_Attrs const *attrs = ((QSPI_Config *)handle)->attrs; QSPI_Object *object = ((QSPI_Config *)handle)->object; QSPI_Transaction *transaction = object->transaction; const CSL_QspiRegs *pReg = (const CSL_QspiRegs *)attrs->baseAddr; /* Get flash offset */ offset = (uintptr_t)transaction->addrOffset; /* Extract memory map mode read command */ mmapReadCmd = (uint32_t)object->readCmd; /* Set the number of address bytes */ CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_NUM_A_BYTES, (object->numAddrBytes - 1)); dummyBytes = object->numDummyBits / 8U; dummyBits = object->numDummyBits % 8U; CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_NUM_D_BITS, dummyBits); CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_NUM_D_BYTES, dummyBytes); CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_RCMD, mmapReadCmd); switch(object->rxLines) { case QSPI_RX_LINES_SINGLE: { CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_READ_TYPE, QSPI_MEM_MAP_READ_TYPE_NORMAL); break; } case QSPI_RX_LINES_DUAL: { CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_READ_TYPE, QSPI_MEM_MAP_READ_TYPE_DUAL); break; } case QSPI_RX_LINES_QUAD: { CSL_REG32_FINS((&pReg->SPI_SETUP0_REG)+(attrs->chipSelect * 0x4U), QSPI_SPI_SETUP0_REG_READ_TYPE, QSPI_MEM_MAP_READ_TYPE_QUAD); break; } default: break; } temp_addr = ((uintptr_t)attrs->memMapBaseAddr + (uintptr_t)transaction->addrOffset); pSrc = ((uint32_t *)(temp_addr)); pDst = (uint32_t *)transaction->buf; count = transaction->count; if (attrs->dmaEnable == true) { QSPI_edmaTransfer(pDst, pSrc, count, handle); } else { while(count > 0) { /* Do the normal memory to memory transfer. Copy will be in bytes */ *pDst = *pSrc; pDst++; pSrc++; count -= 4; } } } else { status = SystemP_FAILURE; } return status; }
And I compared with the original one. The results are shown in following figures:
(1) the original one:
(2) the modified one:
As you can see, the CPU load time is shorter.
Best Regards,
Will
Hi Will,
I am reaching out to the experts for comments on this subject. Thanks for your patience!
Best,
Daniel
Hi Daniel,
I have captured the QSPI CLK waveforms when using DMA to boot the SBL, and I found that the width of DMA accessing to QSPI is 128-bit.
Further I found there are 2 continuous read-access to external Flash when using DMA, and I think it is caused by the default burst size configuration (DBS) of DMA as shown in TRM:
It seems that the SBL configures the DBS to 2'b01 and so that 32 bytes burst reading is used here.
I want to know how to modify the DBS configuration? So that I can modify the DBS configuration to 2'b11 and improve the speed of SBL boot further.
Best Regards,
Will
Hi Will,
The below register can be used to modify the burst mode -
Register:
Field: TPTC_DBS_CONFIG_TPTC_A0 or TPTC_DBS_CONFIG_TPTC_A1
Write value 0x3 to make 128 byte burst transfer
Regards,
Ashwin
Hi Will,
Support for 32-bit or 16-bit access to external Flash device should improve performance. The same applies to DMA too. Currently DMA transfers 1 byte per trigger. If we increase the Word length, the number of DMA triggers would reduce and performance should be improved.
We can look into this and get back post 8.3 release.
Regards,
Ashwin
Hi Ashwin,
I add the following register modification in SBL demo and use it to boot the appimage, it can improve the boot performance as shown in the following two figures.
int32_t status; Bootloader_profileReset(); Bootloader_socConfigurePll(); Bootloader_socInitL2MailBoxMemory(); System_init(); Bootloader_profileAddProfilePoint("System_init"); *((uint32_t *) (0x50D00800)) = 0x3U ;
(1) Modify the TPTC_DBS_CONFIG register:
(2) Default vale of the TPTC_DBS_CONFIG register:
I have also checked the .rprc file of the application, it shows that there are 2 sections for my appimage, one is vector section and another one is the text/data section. The rprc file also contains RPRC header, Section 1 header and Section 2 header and they also need to be transferred between Flash device and MCU. Those headers and vector section is too short to be improved by burst mode. By the way, these headers are all five 32-bit words length and this odd number length will add boot time according to the waveforms of QSPI.
Thanks again for BU's guidance.
Will