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

[Simon Goldschmidt]

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.

Regards,
Simon

> 2018-01-08 11:17 GMT+02:00 Goldschmidt Simon 
> <sgoldschmidt at de.pepperl-fuchs.com 
> <mailto:sgoldschmidt at de.pepperl-fuchs.com>>:
>
>     On Mon, 08/012018 06:27, Vignesh R wrote:
>     > On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
>     > [...]
>     > >>> 1. The indaddrtrig register was being programmed with an
>     incorrect
>     > >>> value for socfpga as the result of assuming it should be
>     programmed
>     > >>> with the same address as the ahbbase address.  This issue is
>     > >>> resolved by adopting the Linux DT bindings, which has an
>     independent
>     > >>> setting for the indaddrtrig register so the register can be
>     set correctly on all
>     > architectures.  Plus it aligns the DT between u-boot and Linux.
>     > >> That should be an easy patch, so this is the patchset
>     0/5..5/5 that
>     > >> you just submitted ?
>     > > Yes. I saw you Acked it, thank you.
>     > >>> 2. The cadence driver was modified at one point to use the
>     bouncebuf
>     > >>> functions to fix an issue on a TI architecture that
>     expected, where
>     > >>> if I recall correctly all reads except the last have to be
>     32-bit
>     > >>> reads.  However, since the bouncebuf was designed for DMA
>     transfers,
>     > >>> it invalidates the data cache after reading, but since the
>     cadence
>     > >>> is using cpu transfers the newly read data is thrown away
>     when the
>     > >>> cache is invalidated.  This issue is resolved by reverting
>     the commit that
>     > introduced using the bounce buffer for read operations, which
>     according to
>     > Vignesh don't cause any issues to the TI architecture.
>     > >> Hmmmmm, I wonder why you need bounce buffer at all here. The
>     CQSPI
>     > >> literally reads/writes a register space (or some FIFO in register
>     > >> space), there is no DMA involved at all. I also wonder why we
>     have to
>     > >> manipulate with cache at all here.
>     > >
>     > > I agree, I don't believe this needs a bounce buffer at all.  This
>     > > isn't a DMA, there is no need for cache manipulation.  Vignesh
>     > > understands the problem better than I do on the TI platform, but I
>     > > believe it was used since it was an easy way to ensure the
>     register read/writes
>     > were all 32-bits wide up until the last read/write.
>     >
>     > Yes, that was the intention. Unfortunately, I chose to use
>     common bounce buffer
>     > implementation which was doing cache manipulations.
>     >
>     > > I believe the bounce buffer should be removed from the CQSPI
>     driver
>     > > and a different solution should be implemented, but Vignesh should
>     > > weigh in on that since it effects his architecture.
>     > >
>     >
>     > CQSPI on TI K2G has problems with non 32 bit aligned write
>     operations.
>     > But read operations are unaffected. Therefore I have Ack'ed
>     Simon's patch
>     > reverting bouncebuf for read. For writes, I have patches to
>     revert common
>     > bouncebuf usage and use a local pagesize buffer for overcome
>     alignment issue. I
>     > am waiting for current patch backlogs to be merged so that its
>     easy for testing w/o
>     > specifying bunch of dependent patches.
>     >
>     > Or if Simon agrees, I can add his patch to my series post it to
>     mailing list (rebased
>     > on top of Jason's series)?
>
>     Well, it's not really "my" patch, anyway. It reverts a commit of
>     yours, so sure, as long as this does not stand in the way of getting
>     qspi running on 2018.03, go ahead and itegrate it in your patchset.
>
>     I'd be happy to have this sent now so I can test both patchsets on
>     top of 2018.01(-rc).
>
>     Thanks,
>     Simon
>
>