Hi Ashish,
On 13.09.19 15:11, Stefan Roese wrote:
On 12.09.19 14:36, Stefan Roese wrote:
<snip>
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:
https://github.com/erashish007/u-boot-spi-mem/tree/spi-mem-port
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
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?
Thanks,
Stefan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
