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
<sgoldschm...@de.pepperl-fuchs.com
<mailto:sgoldschm...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
