Hi Ashish,
On 22.10.19 18:11, Ashish Kumar wrote:
>
>
>> -----Original Message-----
>> From: Stefan Roese <s...@denx.de>
>> Sent: Tuesday, October 22, 2019 9:12 PM
>> To: Schrempf Frieder <frieder.schre...@kontron.de>; Ashish Kumar
>> <ashish.ku...@nxp.com>; Ye Li <ye...@nxp.com>;
>> ja...@amarulasolutions.com
>> Cc: Fabio Estevam <fabio.este...@nxp.com>; u-boot@lists.denx.de; dl-
>> uboot-imx <uboot-...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
