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