[U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms

Wed Oct 23 10:34:03 UTC 2019

Hi Ashish,

On 22.10.19 18:11, Ashish Kumar wrote:
> 
> 
>> -----Original Message-----
>> From: Stefan Roese <sr at denx.de>
>> Sent: Tuesday, October 22, 2019 9:12 PM
>> To: Schrempf Frieder <frieder.schrempf at kontron.de>; Ashish Kumar
>> <ashish.kumar at nxp.com>; Ye Li <ye.li at nxp.com>;
>> jagan at amarulasolutions.com
>> Cc: Fabio Estevam <fabio.estevam at nxp.com>; u-boot at lists.denx.de; dl-
>> uboot-imx <uboot-imx at nxp.com>
>> Subject: Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode
>> setting for latest iMX platforms
>>
>> Caution: EXT Email
>>
>> Hi Frieder,
>>
>> On 22.10.19 15:55, Schrempf Frieder wrote:
>>> Hi Stefan,
>>>
>>> On 22.10.19 15:18, Stefan Roese wrote:
>>>> Hi Frieder,
>>>> Hi Ashish,
>>>> Hi Ye Li,
>>>> Hi Fabio,
>>>>
>>>> On 18.09.19 09:42, Stefan Roese wrote:
>>>>> Hi Frieder,
>>>>>
>>>>> On 18.09.19 09:08, Schrempf Frieder wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>> One further update on this QSPI driver. This driver only works
>>>>>>> when loaded via "imx_usb" on the i.MX6ULL EVK. When programmed
>>>>>>> into QSPI and booted from QSPI this driver does not detect the SPI
>>>>>>> NOR
>>>>>>> flash:
>>>>>>>
>>>>>>> => sf probe
>>>>>>> unrecognized JEDEC id bytes: ff, ff, ff
>>>>>>>
>>>>>>> Do you have any idea what might explain this difference. I would
>>>>>>> have expected that when booting via QSPI it would be "easier" for
>>>>>>> the driver, as the BootROM already initializes the QSPI interface.
>>>>>>> Which is not the case in the boot via serial download (imx_usb)
>>>>>>> mode. Here everyhting (pinmux, clocks, etc) need to be configured.
>>>>>>>
>>>>>>> My feeling is that something is configured "incorrectly" by the
>>>>>>> BootROM in this case which is not re-configured as the QSPI driver
>>>>>>> needs it to be currently.
>>>>>>>
>>>>>>> Do you have any ideas on what might be the problem here? Is there
>>>>>>> something that I can do to help test this? Would it help if I
>>>>>>> would send the debug logging of the driver?
>>>>>>
>>>>>> I have a strong suspicion of what goes wrong in your case. We
>>>>>> experienced exactly the same issue recently on i.MX6ULL. For some
>>>>>> reasons (I guess differences in BootROM) this does not happen on
>>>>>> i.MX6UL.
>>>>>>
>>>>>> The problem is, that the BootROM sets the TDH bits in the
>>>>>> QuadSPI_FLSHCR register to '01' in case it uses the DDR mode.
>>>>>> Afterwards when U-Boot or Linux try to access the flash in SDR
>>>>>> mode, they fail as the TDH bits are still set. Resetting them to '00' solves
>> the problem.
>>>>>>
>>>>>> Unfortunately the TDH bits are not documented in the manual of the
>>>>>> i.MX6UL/ULL, but they can be found in the manual of the i.MX7.
>>>>>>
>>>>>> For the QSPI driver, this means it needs a fix to set/reset the TDH
>>>>>> bits according to the mode that is used (DDR/SDR).
>>>>>>
>>>>>> For more details please also look here:
>>>>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc
>>>>>>
>> ommunity.nxp.com%2Fthread%2F507260&data=02%7C01%7Cashish.ku
>> mar%
>>>>>>
>> 40nxp.com%7Cc03ee11b869c47c9a7d308d757065561%7C686ea1d3bc2b4c6fa
>> 92c
>>>>>>
>> d99c5c301635%7C0%7C0%7C637073557020848801&sdata=ZvRU8vVPq0ll
>> gIF
>>>>>> 56nVugHjTQhM0E1GJ8PPl6P46vrg%3D&reserved=0
>>>>>
>>>>> Perfect. With these bits set to 00 again, booting from QSPI now
>>>>> works on the EVK. Many thanks for this hint! :)
>>>>
>>>> I'm coming back to this issue, as we now have the new NXP patches
>>>> integrated into mainline. Including this one:
>>>>
>>>> 7949576664ac "spi: fsl_qspi: Fix DDR mode setting for latest iMX
>>>> platforms" > I've now re-tested current mainline on the i.MX6ULL Eval
>>>> Kit and QSPI does not work reliably. This is with
>>>> CONFIG_SYS_FSL_QSPI_AHB enabled and disabled. How is QSPI
>> supposed to
>>>> work on i.MX6ULL/ULZ? Is any one of you running this current mainline
>>>> driver successfully on one any i-MX6ULL/ULZ based board? If yes, what is
>> your configuration here?
>>>
>>> I don't have any experience with the current mainline SPI NOR driver.
>>>
>>>>
>>>> BTW: Using the "spi-mem" driver version from Ashish with the fix
>>>> suggested by Frieder to clear the DDR bit in TDH (reset to 00) still
>>>> works without any problems.
>>>
>>> There is some cleanup work that needs to be done (e.g. [1]). After
>>> that I will send an official patch for the spi-mem driver. Then Ashish
>>> and you can comment with your test results and change requests.
>>
>> Sounds like a good plan. Please keep me on Cc on any of these patches, so
>> that I don't forget to review and test them. Thanks in advance.
> 
> Hi Frieder,
> 
> I see one issue with current SPI-MEM driver getting ported in u-boot, that is: access via md command is not working, in order words direct access to flash memory is no more possible, which was previously possible. Such access is helpful to access memory directly and make user experience similar to parallel NOR.

Yes, direct memory-mapped access to the whole flash is not possible with 
this driver. Though I don't see any good reason why someone wants to do 
this, when there's a SPI NOR and MTD layer to abstract the flash and 
handle access to it. You can still use sf and/or mtd commands to 
read/write data between flash and RAM.

> 
> To fix this I had tried these possible changes in driver, change this to q->devtype_data->ahb_buf_size to flash size rather than AHB buffer size.

This is not a good idea. The driver is not designed to do this. In the 
upstream Linux SPI MEM layer, we have a implementation for a direct 
mapping API, that allows the SPI MEM layer to create memory mappings for 
SPI NOR devices. If needed this could be ported to U-Boot, but IMHO it 
should be avoided.

> 
> In function
> fsl_qspi_default_setup() {
> 	/*
> 	 * In HW there can be a maximum of four chips on two buses with
> 	 * two chip selects on each bus. We use four chip selects in SW
> 	 * to differentiate between the four chips.
> 	 * We use ahb_buf_size for each chip and set SFA1AD, SFA2AD, SFB1AD,
> 	 * SFB2AD accordingly.
> 	 */
> 	qspi_writel(q, q->devtype_data->ahb_buf_size + addr_offset,
> 		    base + QUADSPI_SFA1AD);
> 	qspi_writel(q, q->devtype_data->ahb_buf_size * 2 + addr_offset,
> 		    base + QUADSPI_SFA2AD);
> 	qspi_writel(q, q->devtype_data->ahb_buf_size * 3 + addr_offset,
> 		    base + QUADSPI_SFB1AD);
> 	qspi_writel(q, q->devtype_data->ahb_buf_size * 4 + addr_offset, 	
> 		    base + QUADSPI_SFB2AD);	
> 
>>>>>>>>>>>>>>>>
> In function fsl_qspi_exec_op() {
> 		qspi_writel(q, QUADSPI_RBCT_WMRK_MASK |
> 			    QUADSPI_RBCT_RXBRD_USEIPS, base + QUADSPI_RBCT);
> 
> 		if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT)
> 			fsl_qspi_fill_txfifo(q, op);
> 
> 		err = fsl_qspi_do_op(q, op);
> 
> added this line :  spi_writel(q, op->data.nbytes | QUADSPI_IPCR_SEQID(0),  base + QUADSPI_IPCR);
> 
> And set seq_id to 0, Which was initially set by BootROM, after this md works correctly but, sf read is only able to read max data size of rxfifo.
> 
> Could you please suggest what other thing I am missing to get access via md command.

Sorry no, because as already mentioned, this driver and the SPI MEM 
layer is not supposed to work like this. At least not without the direct 
mapping API ([1]).

Regards,
Frieder

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=aa167f3fed0c37e0e4c707d4331d827661f46644