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

[RB23]

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.

2018-01-08 11:17 GMT+02:00 Goldschmidt Simon <
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
>