[U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
frieder.schrempf at kontron.de
Wed Sep 18 07:08:40 UTC 2019
On 18.09.19 06:51, Stefan Roese wrote:
> Hi Ashish,
> On 13.09.19 15:11, Stefan Roese wrote:
>> On 12.09.19 14:36, Stefan Roese wrote:
>>>> The spi-mem version is still under debug, I could make it working
>>>> for ls1088rdb, ls1046rdb, but it is failing for
>>>> ls1012ardb and ls2088ardb and untested for i.mx and other Layerscape
>>>> silicon/boards . It is derived from work done by Frieder earlier.
>>>> This version can be found here:
>>> Many thanks. I did some tests with this version and it seems to work
>>> fine in general on the i.MX6ULL EVK. My first tests show that reading
>>> and writing has no issues. So this is very promising. The only thing
>>> I noticed is, that when using SPI for environment via
>>> CONFIG_ENV_IS_IN_SPI_FLASH, the board hangs upon bootup while trying
>>> to read the env. Since you already added some debug print's to the
>>> env code, I suspect that you also did run into this problem.
>>> I'll try to help with this driver version. At least I can debug this
>>> env issue and can always do some test on my mx6ull platform for you
>>> once you have any updates here. Just let me know.
>> Okay, this one with the env in SPI NOR is fixed. Its a problem with
>> your PR debug printf macro. Please change it this way:
>> -#define PR(fmt, ...) \
>> - fprintf(stderr, "DEBUG: %s:%d:%s(): " fmt" \n", \
>> +#define PR(fmt, ...) \
>> + printf("DEBUG: %s:%d:%s(): " fmt" \n", \
>> With this change, I can successfully boot with SPI NOR environment
>> on my board. I will do some further tests with your driver next
>> week and will get back to you with the results. Please keep me in
>> the loop, if you have updates on the driver.
> 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
> => 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:
More information about the U-Boot