Hi Stephen, On 13 April 2015 at 11:46, Simon Glass <s...@chromium.org> wrote: > 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.
I've pushed a new u-boot-dm/next if you'd like to try it. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
