From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 13 Apr 2015 11:36:49 -0600 Subject: [U-Boot] Testing u-boot-dm/next In-Reply-To: References: <552BEE62.6000306@wwwdotorg.org> <552BF708.4040402@wwwdotorg.org> Message-ID: <552BFEB1.9010701@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/13/2015 11:29 AM, Simon Glass wrote: > Hi Stephen, > > On 13 April 2015 at 11:04, Stephen Warren 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 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.