[U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
sr at denx.de
Wed Sep 18 04:51:00 UTC 2019
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?
More information about the U-Boot