T1024RDB eSPI driver in u-boot (fsl-espi.c)

[eduardkromskoy]

Hi,

Does anyone have properly fixed eSPI driver for u-boot? Original drivers/spi/fsl-espi.c provided with latest Yocto SDK (I checked 2019.03 and 2019.06) is buggy in regard of transmitting long (multi chunks) bit stream and works for SPI flash read command only. We modified the driver to use Transmit only capabilities of T1024 eSPI and it works fine to configure FPGA. We didn't use SPI flash for booting till now. Now we have new hardware board where we need to boot from SPI flash (so, transmit only driver cannot read image from flash) and at the same time we need to configure FPGA on the board (which original driver cannot do at all). NXP doesn't seem to have any plans to fix their eSPI driver.

So, if anyone already have done this fix to properly shift SPI data in and out, so it can be used to read SPI flash as well as to program FPGA, could you share it.

Thank you very much,

Ed

[Pavel]

These limitations are the T1024 hardware limitations. There is no possibility to overcome these limitations.

If long SPI transfers are needed for your FPGA use different GPIO as FPGA SPI CS.

Have a great day,
Pavel Chubakov

[Pavel]

See Note to the SPI_BASE bits in the Table 4 of the T1024 Reference Manual:

If cfg_rcw_src selects an SPI option as the RCW source, the SPI pins used for loading the RCW SPI_MOSI, SPI_MISO, SPI_CLK, SPI_CS_B[0] are driven with SPI

See also the Sections 3.4 and 3.4.7 of the T1024 Reference Manual. This Section shows that RCW is used for multiplexing of these pins.

Have a great day,
Pavel Chubakov

[eduardkromskoy]

Hi Pavel,

Thank you very much for pointing that out. That was exactly what I discovered briefly looking into existing driver. I also included quotes from documentation stating that eSPI controller always insert minimum 1 clock cycle CS negation between transfers (what a weird limitation) and that SPI_CS_B[0] pin won't be controlled as GPIO if booting from SPI flash. Basically, my original question was how to overcome any of these two limitations. Please don't quote manuals because I have read them already.

Have a nice day,

Ed.

[Pavel]

Pins assignment of the eSPI/eSDHC/GPIO2 depends on RCW[SPI_BASE] and RCW[SPI_EXT] settings. There are no other register for changing this pin assignment.

Have a great day,
Pavel Chubakov

[eduardkromskoy]

Hi Pavel,

That statement is not completely correct. Even though you select RCW[SPI_EXT] = 000 and RCW[SPI_BASE] = 10 which means GPIO2; when you boot from SPI flash SPI_CS_B[0] pin is controlled by eSPI controller and ignores GPIO2 block.

[Pavel]

Do not connect the SPI_CS_B[0] to your FPGA.

Connect any GPIO to FPGA SPI CS.

This GPIO can be used as FPGA SPI CS.

Set low level on this GPIO before data transfers and set high level after data transfers.

Have a great day,
Pavel Chubakov

[eduardkromskoy]

Hi Pavel,

I will try to explain the problem again. Please leave alone FPGA. There is no problem with FPGA and it is not connected to SPI_CS_B[0]. However, my system must be able to boot from SPI flash and SPI boot flash must be connected to SPI_CS_B[0]. Moreover, when cfg_rcw_src pins point to SPI flash as a source, RCW[SPI_BASE] and RCW[SPI_EXT] are ignored and SPI_CS_B[0] line is controlled by eSPI. It's done because RCW and first stage loader should be loaded into SRAM by PBL. From first stage boot loader I want to honor RCW[SPI_BASE] and RCW[SPI_EXT] settings from now on and switch off SPI_CS_B[0] line be controlled by eSPI but behave as regular GPIO line. How can I do it? There must be some SoC control register that must be updated, I hope. 

Thank you,

Ed

[Pavel]

Question number two:

It looks like that this SPL code can be used for setting the SPI_CS_B[0] line to be GPIO and using this GPIO as SPI_CS.

Different solution if different GPIO is used as SPI CS for your FPGA. Use your software for assertion/negation of this GPIO. Software can assert this GPIO for a few SPI transfers from the T1024 to your FPGA.

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[eduardkromskoy]

Hi Pavel,

How do I change usage of SPI_CS_B[0] line to be GPIO in SPL? What CPU/SoC register can I modify so the line would be free for GPIO usage? FPGA is on different CS and there is no problem accessing other SPI slave devices. I have implemented simple eSPI driver using GPIO2[0:3] to select slave device and form single SPI transfer by multiple frames. It work fine with one exception. If system boots from SPI flash (and SPI flash must be CS0 device) the settings for GPIO2_00 pin from RCW are ignored. In SPL code my driver does work with CS[1:3] but not with CS0 which I ultimately need to read the rest of image from SPI flash. So, the question is how to cancel GPIO2_00/CS0 pin to be controlled by eSPI and make it plain GPIO line.

Thank you,

Ed

[eduardkromskoy]

Hi,

Since nobody suggested any available source I briefly looked into this driver.

It looks like two frames cannot be concatenated into one SPI transfer without de-asserting CS signal. ESPI_SPMODEx register has CSxCG gap parameter which says: "Clock gap - insert gaps between transmitted frames according to this size (during this time, chip select is negated). Chip select is negated minimum time of 1 bit time."

So, question number one: Can it be avoided somehow (like using other timing settings CS before and after frame; something not really well documented anywhere) in a way that chip select is not negated between frames?

To by-pass this limitation I have chosen RCW[SPI_EXT] == '000' and RCW[SPI_BASE] == '10' effectively choosing to control chip selects signals as GPIO2[0:3]. It works fine with some exception: if I boot target from SPI flash it doesn't work.

RCW.[SPI_BASE] has this note: "If cfg_rcw_src selects an SPI option as the RCW source, the SPI pins used for loading
the RCW SPI_MOSI, SPI_MISO, SPI_CLK, SPI_CS_B[0] are driven with SPI functionality regardless of the setting of this field.". I understand that this is required by CPU firmware to load first stage loader (SPL) into SRAM (CPU cache).

So, question number two: Can I somehow reset this behaviour since SPL is already loaded and before I load full loader image into DRAM I want to switch SPI_CS_B[0] line to be GPIO controlled as it happens when target is booting from any other source? 

Thank you in advance. I really hope someone with real experience could help in this muddy matter.

Ed