Hi Stephen, On 13 April 2015 at 11:36, Stephen Warren <swar...@wwwdotorg.org> wrote: > > On 04/13/2015 11:29 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 13 April 2015 at 11:04, Stephen Warren <swar...@wwwdotorg.org> wrote: >>> >>> On 04/13/2015 10:27 AM, Stephen Warren wrote: >>>> >>>> >>>> On 04/08/2015 09:11 PM, Simon Glass wrote: >>>>> >>>>> >>>>> (Correcting address for Masahiro, sorry) >>>>> >>>>> On 8 April 2015 at 21:07, Simon Glass <s...@chromium.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have quite a few patches queued up in the next branch of u-boot-dm, >>>>>> ready for when the merge window options. >>>>>> >>>>>> If anyone has time and can give it a spin on their board, it would be >>>>>> much >>>>>> appreciated! >>>> >>>> >>>> >>>> On Jetson TK1, there's something up with USB. >>> >>> >>> ... >>>> >>>> >>>> ... and here's u-boot-dm/next >>>> >>>>> Tegra124 (Jetson TK1) # usb start >>>>> starting USB... >>>>> USB-1: USB EHCI 1.10 >>>>> scanning bus 0 for devices... 1 USB Device(s) found >>>>> USB-1: USB EHCI 1.10 >>>>> >>>>> scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 >>>>> USB device not accepting new address (error=2) >>>>> EHCI timed out on TD - token=0x80008d80 >>>>> >>>>> USB device not accepting new address (error=2) >>>>> 4 USB Device(s) found >>>>> scanning usb for ethernet devices... 0 Ethernet Device(s) found >>> >>> >>> >> >> I saw that too, and not just on Tegra. But in my testing it didn't >> happen on every run and it happened before and after switching to >> driver model. Can you check by running it 5 times? >> >> I saw a report of this problem on the mailing list so figured it was >> unrelated. For now I can remove this patch from dm/next, but I'll wait >> to hear from you. > > > I already checked the bisect result 5 times on the bad and immediately > preceding good commit. > >>> ... >>>> >>>> >>>> Seaboard/Springbank appears to have the same issue. Additionally, the >>>> flashing process spews a ton of: >>>> >>>> ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 >>>> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28 >> >> >> This is supposed to use alloc_priv() in drivers/core/device.c to >> allocate a DMA-aligned address. I wonder which buffer is causing this >> problem? I'll check it out on seaboard - I did most of my testing on >> Jetson only a sanity check on seaboard, so perhaps something broke in >> the meantime. > > > It looks like this one in tegra_nand.c:nand_rw_page(): > > dma_prepare(buf, 1 << chip->page_shift, is_writing); > > ... which is odd since I thought that "buf" was simply the user-supplied > buffer, incremented by the NAND page size each time. I'll trace through the > code a bit more. > >>> Both of those bisect to: >>> >>> 7bf0b2d00982 dm: usb: tegra: Move to driver model for USB >>> >>> I wonder if the NAND issue is just a bug that's triggered by stack/data >>> layout changes, and that commit tickles it? >> >> >> Which NAND issue? > > > The cache alignment errors during NAND write.
Ah OK, I thought you were saying this was a USB issue. I can't see how the driver model updates would affect NAND except as you say, that the commit changes the data/bss section layout. For now I'm going to drop this commit from dm/next, since it might take a bit of time to figure things out. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
