| Message ID | 552BF708.4040402@wwwdotorg.org |
|---|---|
| State | RFC |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Stephen, On 13 April 2015 at 11:04, Stephen Warren <swarren@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 <sjg@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. > ... >> >> 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. > > 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? > > For testing, it may be easier to load U-Boot into RAM that flash it every > time. If so, since there's only 1 USB port, you'll need to use "usb reset" > to re-scan that USB port. That will only work with the following patch, > which I'll send in a minute: > > diff --git a/include/configs/tegra-common-post.h > b/include/configs/tegra-common-post.h > index c3ad8beb903d..9ab58555378c 100644 > --- a/include/configs/tegra-common-post.h > +++ b/include/configs/tegra-common-post.h > @@ -26,10 +26,11 @@ > #define STDIN_KBD_KBC "" > #endif > > -#ifdef CONFIG_USB_KEYBOARD > +#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD) > #define STDIN_KBD_USB ",usbkbd" > #define CONFIG_SYS_USB_EVENT_POLL > #define CONFIG_PREBOOT "usb start" > +#define CONFIG_SYS_STDIO_DEREGISTER > #else > #define STDIN_KBD_USB "" > #endif > Regards, Simon
On 04/13/2015 11:29 AM, Simon Glass wrote: > Hi Stephen, > > On 13 April 2015 at 11:04, Stephen Warren <swarren@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 <sjg@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.
Hi Stephen, On 13 April 2015 at 11:36, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 04/13/2015 11:29 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 13 April 2015 at 11:04, Stephen Warren <swarren@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 <sjg@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
Hi Stephen, On 13 April 2015 at 11:46, Simon Glass <sjg@chromium.org> wrote: > Hi Stephen, > > On 13 April 2015 at 11:36, Stephen Warren <swarren@wwwdotorg.org> wrote: >> >> On 04/13/2015 11:29 AM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 13 April 2015 at 11:04, Stephen Warren <swarren@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 <sjg@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
On 04/13/2015 11:52 AM, Simon Glass wrote: ... >>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote: >>>>>>>> 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! ... > I've pushed a new u-boot-dm/next if you'd like to try it. (On Seaboard at least) this solves the two problems we were discussing: * Cache alignment issues during NAND writes. * Failure to enumerate some USB devices. However, I just noticed that USB keyboard support doesn't work (On Seaboard at least). I've bisect this to: 6105422c50ee dm: usb: Move descriptor setup code into its own function
Hi Stephen, On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 04/13/2015 11:52 AM, Simon Glass wrote: > ... >>>>>>>> >>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>> >>>>>>>>> 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! > > ... >> >> I've pushed a new u-boot-dm/next if you'd like to try it. > > > (On Seaboard at least) this solves the two problems we were discussing: > * Cache alignment issues during NAND writes. > * Failure to enumerate some USB devices. > > However, I just noticed that USB keyboard support doesn't work (On Seaboard > at least). I've bisect this to: > > 6105422c50ee dm: usb: Move descriptor setup code into its own function Interesting - there is a small change in that function which I thought was safe, but apparently not. I'll revert it and re-test later today, and let you know when it is ready. Regards, Simon
Hi Stephen, On 13 April 2015 at 14:17, Simon Glass <sjg@chromium.org> wrote: > Hi Stephen, > > On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 04/13/2015 11:52 AM, Simon Glass wrote: >> ... >>>>>>>>> >>>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>> 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! >> >> ... >>> >>> I've pushed a new u-boot-dm/next if you'd like to try it. >> >> >> (On Seaboard at least) this solves the two problems we were discussing: >> * Cache alignment issues during NAND writes. >> * Failure to enumerate some USB devices. >> >> However, I just noticed that USB keyboard support doesn't work (On Seaboard >> at least). I've bisect this to: >> >> 6105422c50ee dm: usb: Move descriptor setup code into its own function > > Interesting - there is a small change in that function which I thought > was safe, but apparently not. I'll revert it and re-test later today, > and let you know when it is ready. Actually that was another patch I was thinking off. I tested the series with two different keyboards at the time (which is why I had to add the later patch to move USB keyboards over to drive model), but obviously I did something wrong as when I test it now, it does not work. Oh dear. I fixed up the three refactoring patches and have resent them to the list. I've also updated u-boot-dm/next if you have time to test again. Both keyboards work for me on seaboard now. I did consider just adding a fixup patch to the end, but I don't like the idea of USB keyboard being broken for many patches if someone later bisects the tree. Thanks for helping test this. I suspect there might be other problems that will show up when more people try it out, but there is plenty of time to deal with that. Regards, Simon
Hi, On 13 April 2015 at 21:25, Simon Glass <sjg@chromium.org> wrote: > > Hi Stephen, > > On 13 April 2015 at 14:17, Simon Glass <sjg@chromium.org> wrote: > > Hi Stephen, > > > > On 13 April 2015 at 13:03, Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 04/13/2015 11:52 AM, Simon Glass wrote: > >> ... > >>>>>>>>> > >>>>>>>>> On 8 April 2015 at 21:07, Simon Glass <sjg@chromium.org> wrote: > >>>>>>>>>> > >>>>>>>>>> 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! > >> > >> ... > >>> > >>> I've pushed a new u-boot-dm/next if you'd like to try it. > >> > >> > >> (On Seaboard at least) this solves the two problems we were discussing: > >> * Cache alignment issues during NAND writes. > >> * Failure to enumerate some USB devices. > >> > >> However, I just noticed that USB keyboard support doesn't work (On Seaboard > >> at least). I've bisect this to: > >> > >> 6105422c50ee dm: usb: Move descriptor setup code into its own function > > > > Interesting - there is a small change in that function which I thought > > was safe, but apparently not. I'll revert it and re-test later today, > > and let you know when it is ready. > > Actually that was another patch I was thinking off. I tested the > series with two different keyboards at the time (which is why I had to > add the later patch to move USB keyboards over to drive model), but > obviously I did something wrong as when I test it now, it does not > work. Oh dear. This may be because I did most of my testing with XHCI which uses a different code path. The code sequence of USB init is quite complex, but it seems that most of this complexity is unfortunately needed for the various cases that come up. Regards, Simon
diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index c3ad8beb903d..9ab58555378c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -26,10 +26,11 @@ #define STDIN_KBD_KBC "" #endif -#ifdef CONFIG_USB_KEYBOARD +#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD) #define STDIN_KBD_USB ",usbkbd" #define CONFIG_SYS_USB_EVENT_POLL #define CONFIG_PREBOOT "usb start" +#define CONFIG_SYS_STDIO_DEREGISTER #else #define STDIN_KBD_USB "" #endif