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 marex@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