On 07/01/2014 03:31 PM, Stephen Warren wrote: > On 07/01/2014 03:25 PM, Jörg Krause wrote: >> >> On 07/01/2014 07:41 PM, Stephen Warren wrote: >>> From: Stephen Warren <swar...@nvidia.com> >>> >>> This is a series of small fixes and cleanups either required by those >>> fixes, or enabled now that the fixes are made. >>> >>> I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but >>> I'm not sure that will happen. The other patches shouldn't change any >>> behaviour. >>> >>> Stephen Warren (6): >>> usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe() >>> usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs >>> usb: ci_udc: lift ilist size calculations to global scope >>> usb: ci_udc: fix items array size/stride calculation >>> usb: ci_udc: remove controller.items array >>> usb: ci_udc: don't memalign() struct ci_req allocations >>> >>> drivers/usb/gadget/ci_udc.c | 62 >>> ++++++++++++++++++++++----------------------- >>> drivers/usb/gadget/ci_udc.h | 1 - >>> 2 files changed, 30 insertions(+), 33 deletions(-) >>> >> >> Good news! The last patch usb: ci_udc: don't memalign() struct ci_req >> allocations removes the timeout error after starting the fourth run of >> tftp in a row. >> >> This is how I tested. Checked out u-boot-usb/master branch. Applied the >> necessary patches to support our board. Applied the patches step after >> step. After applying a patch reset the board and run tftp from console >> until an error occured, which is always the fourth run. > > How many times did you boot the board for each patch? I'm more > interested in how often the first TFTP after a reset/power-on passes or > fails, so it would be nice to boot the board many times to see what > happens to the first TFTP invocation too. This is especially true since > you'd indicated before that the problem was (at least sometimes) visible > on the first TFTP invocation, and this "it fails the fourth time" > symptom is something completely new. > >> This is the case >> until applying patch usb: ci_udc: don't memalign() struct ci_req >> allocations, which throws no timeout error within running tftp about 60 >> times in a row. > > That's quite odd. That patch definitely should not affect behaviour (and > indeed I only sent it as an after-thought). If it does, then the only > explanation I can think of is that the malloc heap's alignment changed, > which just happens to hide the bug you're seeing. No doubt, there is > still some lingering cache-flushing bug or similar... > > BTW, did you fix the U-Boot header files in your board support patches, > so that everything correctly knows that the cache line size is 32? I > think it's mandatory to fix that issue before testing the USB code.
Can you please try one more thing: Go back to u-boot-usb/master plus just your board support patches. Apply the following and test that: > diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c > index a6433e8d2d8d..13be1b73d3d1 100644 > --- a/drivers/usb/gadget/ci_udc.c > +++ b/drivers/usb/gadget/ci_udc.c > @@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int > gfp_flags) > ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req)); > if (!ci_req) > return NULL; > + memset(ci_req, 0, sizeof(*ci_req)); > > INIT_LIST_HEAD(&ci_req->queue); > - ci_req->b_buf = 0; > > if (num == 0) > controller.ep0_req = ci_req; Thanks. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot