On 18.01.2018 06:07, Jason Rush wrote:
On 1/17/2018 7:46 AM, RB23 wrote:
i checked, and if you mean these patches:
https://patchwork.ozlabs.org/patch/765992/
https://patchwork.ozlabs.org/patch/765996/
https://patchwork.ozlabs.org/patch/765997/
https://patchwork.ozlabs.org/patch/765998/
i already applied them, and they didn't work as well.
i also found these patches which i didn't try yet:
https://lists.denx.de/pipermail/u-boot/2017-May/292230.html
should i try those instead?
2018-01-17 15:09 GMT+02:00 Marek Vasut <ma...@denx.de>:
On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
On 17.01.2018 14:01, RB23 wrote:
hey, i downloaded the september and november versions and i applied
the patches on both of them, re-compiled the u boot,
and still, it gives me the same error when trying the command "sf probe"
i'm not sure what to do, is it possible that i missed something? like
a define or something in the make menuconfig?
i did some debugging and it seems that the crash happens on this line:
div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
thanks.
I don't know exactly which patches you are talking about, but the
divide-by-zero problem is still present with all patches I applied. To
fix it, you need to set up your device tree correctly so that the speed
is initialized.
If I remember correctly, you need need to have a flash chip below the
qspi in the device tree. Check Jason's changes to the various socfpga
dts files.
Er, maybe a patch which checks this condition wouldn't hurt ?
Hmm, the problem here is not specific to cadence_qspi, but to the clock
rate calculation in an upper layer (as Jason wrote below). From the ML,
I got the impression it's OK like that (which I don't think it is, it
should at least give a hint what's going wrong instead of a data abort).
However, I'll try to prepare a patch for that as soon as I find the time.
Regards,
Simon
--
Best regards,
Marek Vasut
I re-tested on a Cyclone V SoCKit devboard and a custom Arria V board using the
DTS
patches I submitted (the 4 you mentioned above) and Vignesh's patch to fix the
cache
invalidation problem, and I don't get the divide-by-zero problem. This looks
like the
clock rate for the flash part isn't getting set and is defaulting to 0 for some
reason.
I would look at your device tree. Are you using a stock device tree, or is
this a custom
board? Make sure the 'spi-max-frequency' is being set for the flash part that
is a child
to the cadence qspi node in the device tree.
-- Jason
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
