On Wed, 22 Apr 2020 at 06:33, Nicolas Saenz Julienne <[email protected]> wrote: > > On Wed, 2020-04-22 at 14:01 +0200, Sylwester Nawrocki wrote: > > Hi Nicolas, > > > > (fixed Simon's email address, apologies for mistyping it, I will make sure > > it's correct in next iteration) > > > > On 22.04.2020 10:53, Nicolas Saenz Julienne wrote: > > > I've been trying to get this working on my own and got stuck with this > > > specific > > > issue. I'm glad you found a solution, it was driving me crazy. > > > > > > Out of curiosity how did you found the solution? > > > > It took me many days of debugging...given my nearly non existent previous > > experience in u-boot development.In short, it started with a suggestion to > > map > > all memory for CPU as uncached. > > As in such a case booting was failing I checked where the xhci shared buffer > > allocation fall and created only a small uncached window to cover those > > allocations. This was first thing that started working, after fixing the > > 64-bit pointers setup in XHCI registers. > > Then I discovered "dcache" command and that was also helpful. It was > > sufficient > > to run "dcache off; usb start; dcache on". Then USB worked even after "usb > > reset" > > IIRC. But that was with my old development branch based on v2019.10-rc4 tag. > > Marek tried the same with newer tree and dcache_disable() was not helping, > > but dcache_flush_all() was. > > > > By moving dcache_disable(), dcache_enable() around I found out that it was > > sufficient to disable dcache before xhci_start() call and to enable it right > > afterwards. > > > > Then I just "bisected" the uncached memory region which narrowed it roughly > > to the scratchpad buffer allocations. By inspecting the code carefully again > > it turned there is one more cache flush call needed. > > Thanks for the in-depth explanation, it's very much appreciated!
Yes indeed, thank you! - Simon
