Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 09/27/2017 06:54 AM, Hannes Schmelzer wrote:
On 09/22/2017 02:20 PM, Clément Péron wrote:
Sorry these are my local commits you can find them here :
https://patchwork.ozlabs.org/patch/765992/ https://patchwork.ozlabs.org/patch/765996/ https://patchwork.ozlabs.org/patch/765997/ https://patchwork.ozlabs.org/patch/765998/
Hi, just tested this on my cyclone5 board, but unfortunately without success.
U-Boot SPL 2017.09-00354-g824def8 (Sep 27 2017 - 06:47:19) (....) Hit any key to stop autoboot: 0 => sf probe SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
### ERROR ### Please RESET the board ###
same behavior as before.
Have you compared your dts to the other socfpga_cyclone5_*.dts files?
I have tested this on the socrates board and it would also give me the above error until I change the "compatible" string of the flash chip from "n25q00" to "spi-flash".
Without that, the sf code seems to try to use the first child node as flash chip which results in a divide-by-zero error because it passes a frequency of 0 Hz to the set_speed callback of the qspi driver, which it is not prepared to handle:
If cadence_qspi_apb_config_baudrate_div is called with sclk_hz == 0, the DIV_ROUND_UP macro fails to check the denominator for zero.
I wonder where this should be fixed: in the core sf code or in this driver...
Regards, Simon

Hi Simon,
Disable the data cache tooI change the "compatible" string of the flash chip
from "n25q00" to "spi-flash". Yes, missed to mention these steps.
Did you also test the saveenv and sf unlock ?
Did you get some strange behaviors after a "warm reboot" from linux ? A week that i'm using a new u-boot but i catch some strange behavior after a reboot from linux.
Regards, Clement

Clément Péron wrote: Hi,
Did you get some strange behaviors after a "warm reboot" from linux ? A week that i'm using a new u-boot but i catch some strange behavior after a reboot from linux.
there may some issue since linux can set the flash into another (4byte) addressing mode which can cause trouble if u-boot try read with the standard adressing mode (3byte).
i've seen on some hardware platforms that there is a reset signal wired to the flash which resets this addressing mode setting on warm restart.
Regards, Clement
cheers, Hannes
participants (3)
-
Clément Péron
-
Goldschmidt Simon
-
Hannes Schmelzer