* [U-Boot] Issue with USB mass storage (thumb drives) @ 2016-02-02 10:35 Schrempf Frieder 2016-02-02 16:28 ` Fabio Estevam 0 siblings, 1 reply; 52+ messages in thread From: Schrempf Frieder @ 2016-02-02 10:35 UTC (permalink / raw) To: u-boot Hello, I'm using U-Boot on a custom i.MX6 board and I'm having problems while reading (large) files from USB thumb drives. I wouldn't really mind if this only happened with some specific USB device, but the problem occurs with 3 out of 4 tested thumb drives while loading a 100M test file. The devices that work seem to be rather old ones. The same issue is also reported here: https://community.freescale.com/thread/377911 I can reproduce this behaviour with u-boot-imx v2014.04 and with mainline u-boot v2015.10 and v2016.01. Can someone tell me if this is a known issue? What could be the reason for this and how can I get this working? Thanks! U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) CPU: Freescale i.MX6SOLO rev1.3 at 792MHz CPU: Industrial temperature grade (-40C to 105C) at 31C Reset cause: POR Board: MX6EXCEET DRAM: 1 GiB NAND: 256 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 MiB No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: Found Micrel KS8051/KS8081 PHY FEC Hit any key to stop autoboot: 0 => usb start starting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found => fatload usb 0 0x18000000 test.file reading test.file EHCI timed out on TD - token=0xac008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x128d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x801f8c80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 EHCI timed out on TD - token=0x80008d80 Error reading cluster ** Unable to read file test.file ** ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-02 10:35 [U-Boot] Issue with USB mass storage (thumb drives) Schrempf Frieder @ 2016-02-02 16:28 ` Fabio Estevam 2016-02-02 16:39 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Fabio Estevam @ 2016-02-02 16:28 UTC (permalink / raw) To: u-boot Adding Marek in case he has any ideas. On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder <frieder.schrempf@exceet.de> wrote: > Hello, > > I'm using U-Boot on a custom i.MX6 board and I'm having problems while > reading (large) files from USB thumb drives. > I wouldn't really mind if this only happened with some specific USB > device, but the problem occurs with 3 out of 4 tested thumb drives while > loading a 100M test file. > The devices that work seem to be rather old ones. > > The same issue is also reported here: > https://community.freescale.com/thread/377911 > > I can reproduce this behaviour with u-boot-imx v2014.04 and with > mainline u-boot v2015.10 and v2016.01. > > Can someone tell me if this is a known issue? > What could be the reason for this and how can I get this working? > > Thanks! > > > U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) > > CPU: Freescale i.MX6SOLO rev1.3 at 792MHz > CPU: Industrial temperature grade (-40C to 105C) at 31C > Reset cause: POR > Board: MX6EXCEET > DRAM: 1 GiB > NAND: 256 MiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 MiB > No panel detected: default to Hannstar-XGA > Display: Hannstar-XGA (1024x768) > In: serial > Out: serial > Err: serial > Net: Found Micrel KS8051/KS8081 PHY > FEC > Hit any key to stop autoboot: 0 > => usb start > starting USB... > USB0: Port not available. > USB1: USB EHCI 1.00 > scanning bus 1 for devices... 2 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > scanning usb for ethernet devices... 0 Ethernet Device(s) found > => fatload usb 0 0x18000000 test.file > reading test.file > EHCI timed out on TD - token=0xac008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x128d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x801f8c80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x801f8c80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x801f8c80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x801f8c80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > Error reading cluster > ** Unable to read file test.file ** ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-02 16:28 ` Fabio Estevam @ 2016-02-02 16:39 ` Marek Vasut 2016-02-03 7:40 ` Schrempf Frieder 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-02 16:39 UTC (permalink / raw) To: u-boot On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: > Adding Marek in case he has any ideas. > > On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder > > <frieder.schrempf@exceet.de> wrote: > > Hello, > > > > I'm using U-Boot on a custom i.MX6 board and I'm having problems while > > reading (large) files from USB thumb drives. > > I wouldn't really mind if this only happened with some specific USB > > device, but the problem occurs with 3 out of 4 tested thumb drives while > > loading a 100M test file. > > The devices that work seem to be rather old ones. > > > > The same issue is also reported here: > > https://community.freescale.com/thread/377911 > > > > I can reproduce this behaviour with u-boot-imx v2014.04 and with > > mainline u-boot v2015.10 and v2016.01. > > > > Can someone tell me if this is a known issue? > > What could be the reason for this and how can I get this working? > > > > Thanks! > > > > > > U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) > > > > CPU: Freescale i.MX6SOLO rev1.3 at 792MHz > > CPU: Industrial temperature grade (-40C to 105C) at 31C > > Reset cause: POR > > Board: MX6EXCEET > > DRAM: 1 GiB > > NAND: 256 MiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 > > MiB No panel detected: default to Hannstar-XGA > > Display: Hannstar-XGA (1024x768) > > In: serial > > Out: serial > > Err: serial > > Net: Found Micrel KS8051/KS8081 PHY > > FEC > > Hit any key to stop autoboot: 0 > > => usb start > > starting USB... > > USB0: Port not available. > > USB1: USB EHCI 1.00 > > scanning bus 1 for devices... 2 USB Device(s) found > > > > scanning usb for storage devices... 1 Storage Device(s) found > > scanning usb for ethernet devices... 0 Ethernet Device(s) found > > > > => fatload usb 0 0x18000000 test.file > > reading test.file > > EHCI timed out on TD - token=0xac008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x128d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x801f8c80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x801f8c80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x801f8c80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x801f8c80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > EHCI timed out on TD - token=0x80008d80 > > Error reading cluster > > ** Unable to read file test.file ** What happens if you do 'dcache off' and then read the file ? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-02 16:39 ` Marek Vasut @ 2016-02-03 7:40 ` Schrempf Frieder 2016-02-03 7:45 ` Hannes Schmelzer 2016-02-03 9:40 ` Marek Vasut 0 siblings, 2 replies; 52+ messages in thread From: Schrempf Frieder @ 2016-02-03 7:40 UTC (permalink / raw) To: u-boot On 02.02.2016 17:39, Marek Vasut wrote: > On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: >> Adding Marek in case he has any ideas. >> >> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder >> >> <frieder.schrempf@exceet.de> wrote: >>> Hello, >>> >>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while >>> reading (large) files from USB thumb drives. >>> I wouldn't really mind if this only happened with some specific USB >>> device, but the problem occurs with 3 out of 4 tested thumb drives while >>> loading a 100M test file. >>> The devices that work seem to be rather old ones. >>> >>> The same issue is also reported here: >>> https://community.freescale.com/thread/377911 >>> >>> I can reproduce this behaviour with u-boot-imx v2014.04 and with >>> mainline u-boot v2015.10 and v2016.01. >>> >>> Can someone tell me if this is a known issue? >>> What could be the reason for this and how can I get this working? >>> >>> Thanks! >>> >>> >>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) >>> >>> CPU: Freescale i.MX6SOLO rev1.3 at 792MHz >>> CPU: Industrial temperature grade (-40C to 105C) at 31C >>> Reset cause: POR >>> Board: MX6EXCEET >>> DRAM: 1 GiB >>> NAND: 256 MiB >>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 >>> MiB No panel detected: default to Hannstar-XGA >>> Display: Hannstar-XGA (1024x768) >>> In: serial >>> Out: serial >>> Err: serial >>> Net: Found Micrel KS8051/KS8081 PHY >>> FEC >>> Hit any key to stop autoboot: 0 >>> => usb start >>> starting USB... >>> USB0: Port not available. >>> USB1: USB EHCI 1.00 >>> scanning bus 1 for devices... 2 USB Device(s) found >>> >>> scanning usb for storage devices... 1 Storage Device(s) found >>> scanning usb for ethernet devices... 0 Ethernet Device(s) found >>> >>> => fatload usb 0 0x18000000 test.file >>> reading test.file >>> EHCI timed out on TD - token=0xac008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x128d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x801f8c80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> EHCI timed out on TD - token=0x80008d80 >>> Error reading cluster >>> ** Unable to read file test.file ** > What happens if you do 'dcache off' and then read the file ? Unfortunately turning off dcache doesn't seem to change the behaviour. I'm still getting the same error messages. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 7:40 ` Schrempf Frieder @ 2016-02-03 7:45 ` Hannes Schmelzer 2016-02-03 9:34 ` Marek Vasut 2016-02-03 9:40 ` Marek Vasut 1 sibling, 1 reply; 52+ messages in thread From: Hannes Schmelzer @ 2016-02-03 7:45 UTC (permalink / raw) To: u-boot Hi there, i can osberve same strange thing on Xilinx ZYNQ. But really strange is: I'm having a couple of USB-sticks on my desk, about 5pcs. Exactly one of them is working without any trouble. My testfile is ~16MB, with the magic usb-stick i can read the whole 16MB without errors. With all the other sticks i get this timeouts. best regards, Hannes On 02/03/2016 08:40 AM, Schrempf Frieder wrote: > On 02.02.2016 17:39, Marek Vasut wrote: >> On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: >>> Adding Marek in case he has any ideas. >>> >>> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder >>> >>> <frieder.schrempf@exceet.de> wrote: >>>> Hello, >>>> >>>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while >>>> reading (large) files from USB thumb drives. >>>> I wouldn't really mind if this only happened with some specific USB >>>> device, but the problem occurs with 3 out of 4 tested thumb drives while >>>> loading a 100M test file. >>>> The devices that work seem to be rather old ones. >>>> >>>> The same issue is also reported here: >>>> https://community.freescale.com/thread/377911 >>>> >>>> I can reproduce this behaviour with u-boot-imx v2014.04 and with >>>> mainline u-boot v2015.10 and v2016.01. >>>> >>>> Can someone tell me if this is a known issue? >>>> What could be the reason for this and how can I get this working? >>>> >>>> Thanks! >>>> >>>> >>>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) >>>> >>>> CPU: Freescale i.MX6SOLO rev1.3 at 792MHz >>>> CPU: Industrial temperature grade (-40C to 105C) at 31C >>>> Reset cause: POR >>>> Board: MX6EXCEET >>>> DRAM: 1 GiB >>>> NAND: 256 MiB >>>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >>>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total 1 >>>> MiB No panel detected: default to Hannstar-XGA >>>> Display: Hannstar-XGA (1024x768) >>>> In: serial >>>> Out: serial >>>> Err: serial >>>> Net: Found Micrel KS8051/KS8081 PHY >>>> FEC >>>> Hit any key to stop autoboot: 0 >>>> => usb start >>>> starting USB... >>>> USB0: Port not available. >>>> USB1: USB EHCI 1.00 >>>> scanning bus 1 for devices... 2 USB Device(s) found >>>> >>>> scanning usb for storage devices... 1 Storage Device(s) found >>>> scanning usb for ethernet devices... 0 Ethernet Device(s) found >>>> >>>> => fatload usb 0 0x18000000 test.file >>>> reading test.file >>>> EHCI timed out on TD - token=0xac008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x128d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x801f8c80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x801f8c80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x801f8c80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x801f8c80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> EHCI timed out on TD - token=0x80008d80 >>>> Error reading cluster >>>> ** Unable to read file test.file ** >> What happens if you do 'dcache off' and then read the file ? > Unfortunately turning off dcache doesn't seem to change the behaviour. > I'm still getting the same error messages. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 7:45 ` Hannes Schmelzer @ 2016-02-03 9:34 ` Marek Vasut 0 siblings, 0 replies; 52+ messages in thread From: Marek Vasut @ 2016-02-03 9:34 UTC (permalink / raw) To: u-boot On Wednesday, February 03, 2016 at 08:45:27 AM, Hannes Schmelzer wrote: > Hi there, Please do not top-post > i can osberve same strange thing on Xilinx ZYNQ. > > But really strange is: > I'm having a couple of USB-sticks on my desk, about 5pcs. > Exactly one of them is working without any trouble. > > My testfile is ~16MB, with the magic usb-stick i can read the whole 16MB > without errors. > With all the other sticks i get this timeouts. CCing Michal for zynq issues. > best regards, > Hannes > > On 02/03/2016 08:40 AM, Schrempf Frieder wrote: > > On 02.02.2016 17:39, Marek Vasut wrote: > >> On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: > >>> Adding Marek in case he has any ideas. > >>> > >>> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder > >>> > >>> <frieder.schrempf@exceet.de> wrote: > >>>> Hello, > >>>> > >>>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while > >>>> reading (large) files from USB thumb drives. > >>>> I wouldn't really mind if this only happened with some specific USB > >>>> device, but the problem occurs with 3 out of 4 tested thumb drives > >>>> while loading a 100M test file. > >>>> The devices that work seem to be rather old ones. > >>>> > >>>> The same issue is also reported here: > >>>> https://community.freescale.com/thread/377911 > >>>> > >>>> I can reproduce this behaviour with u-boot-imx v2014.04 and with > >>>> mainline u-boot v2015.10 and v2016.01. > >>>> > >>>> Can someone tell me if this is a known issue? > >>>> What could be the reason for this and how can I get this working? > >>>> > >>>> Thanks! > >>>> > >>>> > >>>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) > >>>> > >>>> CPU: Freescale i.MX6SOLO rev1.3 at 792MHz > >>>> CPU: Industrial temperature grade (-40C to 105C) at 31C > >>>> Reset cause: POR > >>>> Board: MX6EXCEET > >>>> DRAM: 1 GiB > >>>> NAND: 256 MiB > >>>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 > >>>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total > >>>> 1 MiB No panel detected: default to Hannstar-XGA > >>>> Display: Hannstar-XGA (1024x768) > >>>> In: serial > >>>> Out: serial > >>>> Err: serial > >>>> Net: Found Micrel KS8051/KS8081 PHY > >>>> FEC > >>>> Hit any key to stop autoboot: 0 > >>>> => usb start > >>>> starting USB... > >>>> USB0: Port not available. > >>>> USB1: USB EHCI 1.00 > >>>> scanning bus 1 for devices... 2 USB Device(s) found > >>>> > >>>> scanning usb for storage devices... 1 Storage Device(s) > >>>> found scanning usb for ethernet devices... 0 Ethernet > >>>> Device(s) found > >>>> > >>>> => fatload usb 0 0x18000000 test.file > >>>> reading test.file > >>>> EHCI timed out on TD - token=0xac008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x128d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x801f8c80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x801f8c80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x801f8c80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x801f8c80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> EHCI timed out on TD - token=0x80008d80 > >>>> Error reading cluster > >>>> ** Unable to read file test.file ** > >> > >> What happens if you do 'dcache off' and then read the file ? > > > > Unfortunately turning off dcache doesn't seem to change the behaviour. > > I'm still getting the same error messages. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 7:40 ` Schrempf Frieder 2016-02-03 7:45 ` Hannes Schmelzer @ 2016-02-03 9:40 ` Marek Vasut 2016-02-03 9:55 ` Fabio Estevam 1 sibling, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-03 9:40 UTC (permalink / raw) To: u-boot On Wednesday, February 03, 2016 at 08:40:00 AM, Schrempf Frieder wrote: > On 02.02.2016 17:39, Marek Vasut wrote: > > On Tuesday, February 02, 2016 at 05:28:42 PM, Fabio Estevam wrote: > >> Adding Marek in case he has any ideas. > >> > >> On Tue, Feb 2, 2016 at 8:35 AM, Schrempf Frieder > >> > >> <frieder.schrempf@exceet.de> wrote: > >>> Hello, > >>> > >>> I'm using U-Boot on a custom i.MX6 board and I'm having problems while > >>> reading (large) files from USB thumb drives. > >>> I wouldn't really mind if this only happened with some specific USB > >>> device, but the problem occurs with 3 out of 4 tested thumb drives > >>> while loading a 100M test file. > >>> The devices that work seem to be rather old ones. > >>> > >>> The same issue is also reported here: > >>> https://community.freescale.com/thread/377911 > >>> > >>> I can reproduce this behaviour with u-boot-imx v2014.04 and with > >>> mainline u-boot v2015.10 and v2016.01. > >>> > >>> Can someone tell me if this is a known issue? > >>> What could be the reason for this and how can I get this working? > >>> > >>> Thanks! > >>> > >>> > >>> U-Boot 2016.01 (Feb 02 2016 - 10:31:32 +0100) > >>> > >>> CPU: Freescale i.MX6SOLO rev1.3 at 792MHz > >>> CPU: Industrial temperature grade (-40C to 105C) at 31C > >>> Reset cause: POR > >>> Board: MX6EXCEET > >>> DRAM: 1 GiB > >>> NAND: 256 MiB > >>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 > >>> SF: Detected EN25Q80 with page size 256 Bytes, erase size 4 KiB, total > >>> 1 MiB No panel detected: default to Hannstar-XGA > >>> Display: Hannstar-XGA (1024x768) > >>> In: serial > >>> Out: serial > >>> Err: serial > >>> Net: Found Micrel KS8051/KS8081 PHY > >>> FEC > >>> Hit any key to stop autoboot: 0 > >>> => usb start > >>> starting USB... > >>> USB0: Port not available. > >>> USB1: USB EHCI 1.00 > >>> scanning bus 1 for devices... 2 USB Device(s) found > >>> > >>> scanning usb for storage devices... 1 Storage Device(s) found > >>> scanning usb for ethernet devices... 0 Ethernet Device(s) > >>> found > >>> > >>> => fatload usb 0 0x18000000 test.file > >>> reading test.file > >>> EHCI timed out on TD - token=0xac008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x128d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x801f8c80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x801f8c80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x801f8c80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x801f8c80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> EHCI timed out on TD - token=0x80008d80 > >>> Error reading cluster > >>> ** Unable to read file test.file ** > > > > What happens if you do 'dcache off' and then read the file ? > > Unfortunately turning off dcache doesn't seem to change the behaviour. > I'm still getting the same error messages. In that case, debug time. Usual problems are bad routing of the tracks on the board , so try with USB 1.1 hub and if that works, that's your problem. You can also try "setenv usb_pgood_delay 10000" , this will increase the time the code takes after reseting root port. Also try adding #define DEBUG to drivers/usb/host/ehci-hcd.c common/usb.c and common/usb_hub.c . You might notice something odd there. The above output shows that your qTD tokens are not processed , see the active bit being set. Details in [1] page 54 (Table 3-16). [1] http://www.intel.com/content/dam/www/public/us/en/documents/technical- specifications/ehci-specification-for-usb.pdf ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 9:40 ` Marek Vasut @ 2016-02-03 9:55 ` Fabio Estevam 2016-02-03 10:15 ` Schrempf Frieder 0 siblings, 1 reply; 52+ messages in thread From: Fabio Estevam @ 2016-02-03 9:55 UTC (permalink / raw) To: u-boot On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > > In that case, debug time. > > Usual problems are bad routing of the tracks on the board , so try with USB 1.1 > hub and if that works, that's your problem. Another suggestion would be to try the 100MB transfer in Linux and see if this works or not. That would help us to narrow down whether this is a hardware or software problem. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 9:55 ` Fabio Estevam @ 2016-02-03 10:15 ` Schrempf Frieder 2016-02-03 11:12 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Schrempf Frieder @ 2016-02-03 10:15 UTC (permalink / raw) To: u-boot On 03.02.2016 10:55, Fabio Estevam wrote: > On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > >> In that case, debug time. >> >> Usual problems are bad routing of the tracks on the board , so try with USB 1.1 >> hub and if that works, that's your problem. > Another suggestion would be to try the 100MB transfer in Linux and see > if this works or not. > > That would help us to narrow down whether this is a hardware or > software problem. Thank you Marek and Fabio for your input! I tried the file transfer in Linux and this seems to work fine. Also we have been using this hardware for quite some time, also with USB mass storage and large files in Linux and I can't remember any problems. For these reasons I think that the hardware is ok. I added the DEBUG defines and here are the lines around one of the timeouts. With my very limited knowledge of how usb works, I can't read much from those messages: dev=4ffa58e0, pipe=c0008483, buffer=4f50a1a0, length=13, req=00000000 TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 TOKEN=0x80008c01 dev=4ffa58e0, pipe=c0008483, buffer=18000000, length=33553920, req=00000000 TOKEN=0x80009d00 dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000 TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 TOKEN=0x8c01 dev=4ffa58e0, pipe=c0008483, buffer=19fffe00, length=33553920, req=00000000 EHCI timed out on TD - token=0xac008d80 dev=4, usbsts=0x40088, p[1]=0x18001205, p[2]=0x0 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a100 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x8d00 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 length 0x0 dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0 req=1 (0x1), type=2 (0x2), value=0 (0x0), index=129 TOKEN=0x8d00 usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 length 0x0 dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0 req=1 (0x1), type=2 (0x2), value=0 (0x0), index=2 TOKEN=0x8d00 dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 TOKEN=0x80008c01 dev=4ffa58e0, pipe=c0008483, buffer=4ffb6d40, length=18, req=00000000 TOKEN=0x80008d00 dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000 TOKEN=0x8d00 ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 10:15 ` Schrempf Frieder @ 2016-02-03 11:12 ` Marek Vasut 2016-02-03 11:49 ` Schrempf Frieder 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-03 11:12 UTC (permalink / raw) To: u-boot On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: > On 03.02.2016 10:55, Fabio Estevam wrote: > > On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > >> In that case, debug time. > >> > >> Usual problems are bad routing of the tracks on the board , so try with > >> USB 1.1 hub and if that works, that's your problem. > > > > Another suggestion would be to try the 100MB transfer in Linux and see > > if this works or not. > > > > That would help us to narrow down whether this is a hardware or > > software problem. > > Thank you Marek and Fabio for your input! > > I tried the file transfer in Linux and this seems to work fine. > Also we have been using this hardware for quite some time, also with USB > mass storage and large files in Linux and I can't remember any problems. > For these reasons I think that the hardware is ok. > > I added the DEBUG defines and here are the lines around one of the > timeouts. With my very limited knowledge of how usb works, I can't read > much from those messages: It'd help if you shared your patch and the whole output. That way we can check if something goes wrong at the beginning. I wonder if we might be facing some misconfiguration of the USB PHY here ? I don't have a MX6Solo . Fabio, any chance you can try ? > dev=4ffa58e0, pipe=c0008483, buffer=4f50a1a0, length=13, req=00000000 > TOKEN=0x8d00 > dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 > TOKEN=0x80008c01 > dev=4ffa58e0, pipe=c0008483, buffer=18000000, length=33553920, req=00000000 > TOKEN=0x80009d00 > dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000 > TOKEN=0x8d00 > dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 > TOKEN=0x8c01 > dev=4ffa58e0, pipe=c0008483, buffer=19fffe00, length=33553920, req=00000000 > EHCI timed out on TD - token=0xac008d80 > dev=4, usbsts=0x40088, p[1]=0x18001205, p[2]=0x0 > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 > length 0x0 > dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a100 > req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 > TOKEN=0x8d00 > usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 > length 0x0 > dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0 > req=1 (0x1), type=2 (0x2), value=0 (0x0), index=129 > TOKEN=0x8d00 > usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 > length 0x0 > dev=4ffa58e0, pipe=80000403, buffer=00000000, length=0, req=4f50a0c0 > req=1 (0x1), type=2 (0x2), value=0 (0x0), index=2 > TOKEN=0x8d00 > dev=4ffa58e0, pipe=c0010403, buffer=4f50a1c0, length=31, req=00000000 > TOKEN=0x80008c01 > dev=4ffa58e0, pipe=c0008483, buffer=4ffb6d40, length=18, req=00000000 > TOKEN=0x80008d00 > dev=4ffa58e0, pipe=c0008483, buffer=4f50a180, length=13, req=00000000 > TOKEN=0x8d00 Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 11:12 ` Marek Vasut @ 2016-02-03 11:49 ` Schrempf Frieder 2016-02-03 16:40 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Schrempf Frieder @ 2016-02-03 11:49 UTC (permalink / raw) To: u-boot On 03.02.2016 12:12, Marek Vasut wrote: > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >> On 03.02.2016 10:55, Fabio Estevam wrote: >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >>>> In that case, debug time. >>>> >>>> Usual problems are bad routing of the tracks on the board , so try with >>>> USB 1.1 hub and if that works, that's your problem. >>> Another suggestion would be to try the 100MB transfer in Linux and see >>> if this works or not. >>> >>> That would help us to narrow down whether this is a hardware or >>> software problem. >> Thank you Marek and Fabio for your input! >> >> I tried the file transfer in Linux and this seems to work fine. >> Also we have been using this hardware for quite some time, also with USB >> mass storage and large files in Linux and I can't remember any problems. >> For these reasons I think that the hardware is ok. >> >> I added the DEBUG defines and here are the lines around one of the >> timeouts. With my very limited knowledge of how usb works, I can't read >> much from those messages: > It'd help if you shared your patch and the whole output. That way we can > check if something goes wrong at the beginning. > > I wonder if we might be facing some misconfiguration of the USB PHY here ? > > I don't have a MX6Solo . Fabio, any chance you can try ? Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ And here the log for the file transfer (different thumb drive and therefore different messages than posted before): http://paste.ubuntu.com/14865349/ The only changes to U-Boot I made is adding my board configuration (derived from Freescale SabreSD config). The only difference from the SabreSD config related to USB is, that I have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 11:49 ` Schrempf Frieder @ 2016-02-03 16:40 ` Marek Vasut 2016-02-03 19:16 ` Sergei Temerkhanov 2016-02-04 8:06 ` Schrempf Frieder 0 siblings, 2 replies; 52+ messages in thread From: Marek Vasut @ 2016-02-03 16:40 UTC (permalink / raw) To: u-boot On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: > On 03.02.2016 12:12, Marek Vasut wrote: > > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: > >> On 03.02.2016 10:55, Fabio Estevam wrote: > >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > >>>> In that case, debug time. > >>>> > >>>> Usual problems are bad routing of the tracks on the board , so try > >>>> with USB 1.1 hub and if that works, that's your problem. > >>> > >>> Another suggestion would be to try the 100MB transfer in Linux and see > >>> if this works or not. > >>> > >>> That would help us to narrow down whether this is a hardware or > >>> software problem. > >> > >> Thank you Marek and Fabio for your input! > >> > >> I tried the file transfer in Linux and this seems to work fine. > >> Also we have been using this hardware for quite some time, also with USB > >> mass storage and large files in Linux and I can't remember any problems. > >> For these reasons I think that the hardware is ok. > >> > >> I added the DEBUG defines and here are the lines around one of the > >> timeouts. With my very limited knowledge of how usb works, I can't read > > > >> much from those messages: > > It'd help if you shared your patch and the whole output. That way we can > > check if something goes wrong at the beginning. > > > > I wonder if we might be facing some misconfiguration of the USB PHY here > > ? > > > > I don't have a MX6Solo . Fabio, any chance you can try ? > > Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ > And here the log for the file transfer (different thumb drive and > therefore different messages than posted before): > http://paste.ubuntu.com/14865349/ > > The only changes to U-Boot I made is adding my board configuration > (derived from Freescale SabreSD config). > The only difference from the SabreSD config related to USB is, that I > have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. The detection seems fine, it even does what it's supposed to do. You have a USB hub somewhere in there, right ? Is it a powered one or not ? What I find weird in the later log is that the failure always happens when the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if that helps. If it does, then you might be overwriting some malloc area of U-Boot or somesuch . Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 16:40 ` Marek Vasut @ 2016-02-03 19:16 ` Sergei Temerkhanov 2016-02-04 8:21 ` Schrempf Frieder 2016-02-04 8:06 ` Schrempf Frieder 1 sibling, 1 reply; 52+ messages in thread From: Sergei Temerkhanov @ 2016-02-03 19:16 UTC (permalink / raw) To: u-boot On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: > On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >> On 03.02.2016 12:12, Marek Vasut wrote: >> > On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >> >> On 03.02.2016 10:55, Fabio Estevam wrote: >> >>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >> >>>> In that case, debug time. >> >>>> >> >>>> Usual problems are bad routing of the tracks on the board , so try >> >>>> with USB 1.1 hub and if that works, that's your problem. >> >>> >> >>> Another suggestion would be to try the 100MB transfer in Linux and see >> >>> if this works or not. >> >>> >> >>> That would help us to narrow down whether this is a hardware or >> >>> software problem. Another thing to try may be limiting the value of USB_MAX_XFER_BLK in common/usb_storage.c Regards, Sergey >> >> >> >> Thank you Marek and Fabio for your input! >> >> >> >> I tried the file transfer in Linux and this seems to work fine. >> >> Also we have been using this hardware for quite some time, also with USB >> >> mass storage and large files in Linux and I can't remember any problems. >> >> For these reasons I think that the hardware is ok. >> >> >> >> I added the DEBUG defines and here are the lines around one of the >> >> timeouts. With my very limited knowledge of how usb works, I can't read >> > >> >> much from those messages: >> > It'd help if you shared your patch and the whole output. That way we can >> > check if something goes wrong at the beginning. >> > >> > I wonder if we might be facing some misconfiguration of the USB PHY here >> > ? >> > >> > I don't have a MX6Solo . Fabio, any chance you can try ? >> >> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ >> And here the log for the file transfer (different thumb drive and >> therefore different messages than posted before): >> http://paste.ubuntu.com/14865349/ >> >> The only changes to U-Boot I made is adding my board configuration >> (derived from Freescale SabreSD config). >> The only difference from the SabreSD config related to USB is, that I >> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. > > The detection seems fine, it even does what it's supposed to do. > > You have a USB hub somewhere in there, right ? Is it a powered one or not ? > > What I find weird in the later log is that the failure always happens when > the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you > have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if > that helps. If it does, then you might be overwriting some malloc area of > U-Boot or somesuch . > > Best regards, > Marek Vasut > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 19:16 ` Sergei Temerkhanov @ 2016-02-04 8:21 ` Schrempf Frieder 2016-02-04 11:28 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Schrempf Frieder @ 2016-02-04 8:21 UTC (permalink / raw) To: u-boot On 03.02.2016 20:16, Sergei Temerkhanov wrote: > On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: >> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>> On 03.02.2016 12:12, Marek Vasut wrote: >>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >>>>>>> In that case, debug time. >>>>>>> >>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>> Another suggestion would be to try the 100MB transfer in Linux and see >>>>>> if this works or not. >>>>>> >>>>>> That would help us to narrow down whether this is a hardware or >>>>>> software problem. > Another thing to try may be limiting the value of USB_MAX_XFER_BLK in > common/usb_storage.c This was a really helpful hint! Thank you Sergei! I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value (65535 -> 8191) and this time the transfer works without timeouts. As we have a customer who needs this working as soon as possible my question now is how to properly solve this. Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these errors? Which value to choose? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-04 8:21 ` Schrempf Frieder @ 2016-02-04 11:28 ` Marek Vasut 2016-02-08 8:41 ` Hannes Schmelzer 2016-02-18 10:05 ` Schrempf Frieder 0 siblings, 2 replies; 52+ messages in thread From: Marek Vasut @ 2016-02-04 11:28 UTC (permalink / raw) To: u-boot On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: > On 03.02.2016 20:16, Sergei Temerkhanov wrote: > > On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: > >> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: > >>> On 03.02.2016 12:12, Marek Vasut wrote: > >>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: > >>>>> On 03.02.2016 10:55, Fabio Estevam wrote: > >>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > >>>>>>> In that case, debug time. > >>>>>>> > >>>>>>> Usual problems are bad routing of the tracks on the board , so try > >>>>>>> with USB 1.1 hub and if that works, that's your problem. > >>>>>> > >>>>>> Another suggestion would be to try the 100MB transfer in Linux and > >>>>>> see if this works or not. > >>>>>> > >>>>>> That would help us to narrow down whether this is a hardware or > >>>>>> software problem. > > > > Another thing to try may be limiting the value of USB_MAX_XFER_BLK in > > common/usb_storage.c > > This was a really helpful hint! Thank you Sergei! > > I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value > (65535 -> 8191) and this time the transfer works without timeouts. > > As we have a customer who needs this working as soon as possible my > question now is how to properly solve this. > Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these > errors? Which value to choose? Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-04 11:28 ` Marek Vasut @ 2016-02-08 8:41 ` Hannes Schmelzer 2016-02-08 14:58 ` Marek Vasut 2016-02-18 10:05 ` Schrempf Frieder 1 sibling, 1 reply; 52+ messages in thread From: Hannes Schmelzer @ 2016-02-08 8:41 UTC (permalink / raw) To: u-boot On 04.02.2016 12:28, Marek Vasut wrote: > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>>>> On 03.02.2016 12:12, Marek Vasut wrote: >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >>>>>>>>> In that case, debug time. >>>>>>>>> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >>>>>>>> see if this works or not. >>>>>>>> >>>>>>>> That would help us to narrow down whether this is a hardware or >>>>>>>> software problem. >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>> common/usb_storage.c >> This was a really helpful hint! Thank you Sergei! >> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >> (65535 -> 8191) and this time the transfer works without timeouts. >> >> As we have a customer who needs this working as soon as possible my >> question now is how to properly solve this. >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >> errors? Which value to choose? > Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? Hi, that tip works also on my ZYNQ board. There is some comment around this 'magic-define': /* * The U-Boot EHCI driver can handle any transfer length as long as there is * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are * limited to 65535 blocks. */ Can i assume that 16MiB free heap space is enough if i want read a 16MiB file ? > Best regards, > Marek Vasut best regards, Hannes ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-08 8:41 ` Hannes Schmelzer @ 2016-02-08 14:58 ` Marek Vasut 2016-02-12 15:53 ` Simon Glass 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-08 14:58 UTC (permalink / raw) To: u-boot On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote: > On 04.02.2016 12:28, Marek Vasut wrote: > > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: > >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: > >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: > >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: > >>>>> On 03.02.2016 12:12, Marek Vasut wrote: > >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: > >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: > >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: > >>>>>>>>> In that case, debug time. > >>>>>>>>> > >>>>>>>>> Usual problems are bad routing of the tracks on the board , so > >>>>>>>>> try with USB 1.1 hub and if that works, that's your problem. > >>>>>>>> > >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and > >>>>>>>> see if this works or not. > >>>>>>>> > >>>>>>>> That would help us to narrow down whether this is a hardware or > >>>>>>>> software problem. > >>> > >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in > >>> common/usb_storage.c > >> > >> This was a really helpful hint! Thank you Sergei! > >> > >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value > >> (65535 -> 8191) and this time the transfer works without timeouts. > >> > >> As we have a customer who needs this working as soon as possible my > >> question now is how to properly solve this. > >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these > >> errors? Which value to choose? > > > > Nice! Can you share which sticks are those, ideally brand/type and USB > > IDs ? > > Hi, > that tip works also on my ZYNQ board. > > There is some comment around this 'magic-define': > > /* > * The U-Boot EHCI driver can handle any transfer length as long as > there is > * enough free heap space left, but the SCSI READ(10) and WRITE(10) > commands are > * limited to 65535 blocks. > */ > > Can i assume that 16MiB free heap space is enough if i want read a 16MiB > file ? The file is actually not read into a buffer on a heap iirc, but directly to the target location if that's in RAM. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-08 14:58 ` Marek Vasut @ 2016-02-12 15:53 ` Simon Glass 2016-02-12 16:04 ` Hannes Schmelzer 0 siblings, 1 reply; 52+ messages in thread From: Simon Glass @ 2016-02-12 15:53 UTC (permalink / raw) To: u-boot Hi, On 8 February 2016 at 07:58, Marek Vasut <marex@denx.de> wrote: > On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote: >> On 04.02.2016 12:28, Marek Vasut wrote: >> > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >> >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >> >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: >> >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >> >>>>> On 03.02.2016 12:12, Marek Vasut wrote: >> >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >> >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >> >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >> >>>>>>>>> In that case, debug time. >> >>>>>>>>> >> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so >> >>>>>>>>> try with USB 1.1 hub and if that works, that's your problem. >> >>>>>>>> >> >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >> >>>>>>>> see if this works or not. >> >>>>>>>> >> >>>>>>>> That would help us to narrow down whether this is a hardware or >> >>>>>>>> software problem. >> >>> >> >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >> >>> common/usb_storage.c >> >> >> >> This was a really helpful hint! Thank you Sergei! >> >> >> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >> >> (65535 -> 8191) and this time the transfer works without timeouts. >> >> >> >> As we have a customer who needs this working as soon as possible my >> >> question now is how to properly solve this. >> >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >> >> errors? Which value to choose? >> > >> > Nice! Can you share which sticks are those, ideally brand/type and USB >> > IDs ? >> >> Hi, >> that tip works also on my ZYNQ board. >> >> There is some comment around this 'magic-define': >> >> /* >> * The U-Boot EHCI driver can handle any transfer length as long as >> there is >> * enough free heap space left, but the SCSI READ(10) and WRITE(10) >> commands are >> * limited to 65535 blocks. >> */ >> >> Can i assume that 16MiB free heap space is enough if i want read a 16MiB >> file ? > > The file is actually not read into a buffer on a heap iirc, but directly to > the target location if that's in RAM. Is it possible that the timeout is genuinely being exceeded? See USB_TIMEOUT_MS in ehci_submit_async(). It looks like 5 seconds to load 32MB, which should be plenty. Perhaps this timeout should be dependent on the data size? I really can't understand why the problem is address-dependent. I'm assuming the cache is set up normally. Regards, Simon ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-12 15:53 ` Simon Glass @ 2016-02-12 16:04 ` Hannes Schmelzer 0 siblings, 0 replies; 52+ messages in thread From: Hannes Schmelzer @ 2016-02-12 16:04 UTC (permalink / raw) To: u-boot On 2016-02-12 16:53, Simon Glass wrote: > Hi, > > On 8 February 2016 at 07:58, Marek Vasut <marex@denx.de> wrote: >> On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote: >>> On 04.02.2016 12:28, Marek Vasut wrote: >>>> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >>>>> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>>>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut <marex@denx.de> wrote: >>>>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>>>>>>> On 03.02.2016 12:12, Marek Vasut wrote: >>>>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >>>>>>>>>>>> In that case, debug time. >>>>>>>>>>>> >>>>>>>>>>>> Usual problems are bad routing of the tracks on the board , so >>>>>>>>>>>> try with USB 1.1 hub and if that works, that's your problem. >>>>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >>>>>>>>>>> see if this works or not. >>>>>>>>>>> >>>>>>>>>>> That would help us to narrow down whether this is a hardware or >>>>>>>>>>> software problem. >>>>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>>>>> common/usb_storage.c >>>>> This was a really helpful hint! Thank you Sergei! >>>>> >>>>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >>>>> (65535 -> 8191) and this time the transfer works without timeouts. >>>>> >>>>> As we have a customer who needs this working as soon as possible my >>>>> question now is how to properly solve this. >>>>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >>>>> errors? Which value to choose? >>>> Nice! Can you share which sticks are those, ideally brand/type and USB >>>> IDs ? >>> Hi, >>> that tip works also on my ZYNQ board. >>> >>> There is some comment around this 'magic-define': >>> >>> /* >>> * The U-Boot EHCI driver can handle any transfer length as long as >>> there is >>> * enough free heap space left, but the SCSI READ(10) and WRITE(10) >>> commands are >>> * limited to 65535 blocks. >>> */ >>> >>> Can i assume that 16MiB free heap space is enough if i want read a 16MiB >>> file ? >> The file is actually not read into a buffer on a heap iirc, but directly to >> the target location if that's in RAM. > Is it possible that the timeout is genuinely being exceeded? See > USB_TIMEOUT_MS in ehci_submit_async(). It looks like 5 seconds to load > 32MB, which should be plenty. Hi Simon, thanks for joining. I also have found this USB_TIMOUT in usb.h and increesed for testing purpose this 5s to about 30s ... without wanted result. It now takes instead 5s this 30s to bring up the timout warning, but still with the effect, that file finally couldn't be read. > Perhaps this timeout should be dependent on the data size? Indeed, it depends on size ... but i'm not sure if this size parameter is 'wired' with some timeout parameter. > I really can't understand why the problem is address-dependent. I'm > assuming the cache is set up normally. This is confusing me also. > Regards, > Simon Hannes ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-04 11:28 ` Marek Vasut 2016-02-08 8:41 ` Hannes Schmelzer @ 2016-02-18 10:05 ` Schrempf Frieder 2016-02-18 15:32 ` Marek Vasut 2016-04-14 13:20 ` Diego 1 sibling, 2 replies; 52+ messages in thread From: Schrempf Frieder @ 2016-02-18 10:05 UTC (permalink / raw) To: u-boot On 04.02.2016 12:28, Marek Vasut wrote: > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut<marex@denx.de> wrote: >>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>>>> On 03.02.2016 12:12, Marek Vasut wrote: >>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut<marex@denx.de> wrote: >>>>>>>>> In that case, debug time. >>>>>>>>> >>>>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >>>>>>>> see if this works or not. >>>>>>>> >>>>>>>> That would help us to narrow down whether this is a hardware or >>>>>>>> software problem. >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>> common/usb_storage.c >> This was a really helpful hint! Thank you Sergei! >> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >> (65535 -> 8191) and this time the transfer works without timeouts. >> >> As we have a customer who needs this working as soon as possible my >> question now is how to properly solve this. >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >> errors? Which value to choose? > Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? At the moment I have two sticks with the same chip around for which setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. Also one of our customers tested a few non-working sticks with this change and reported, that it fixed it for him. Here's a list of those devices, but I guess there are a lot more: 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive, VID: 0x090c, PID: 0x1000 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 3. Newron, VID: 0x8644, PID: 0x800e 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-18 10:05 ` Schrempf Frieder @ 2016-02-18 15:32 ` Marek Vasut 2016-02-18 17:14 ` Fabio Estevam 2016-04-14 13:20 ` Diego 1 sibling, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-18 15:32 UTC (permalink / raw) To: u-boot On 02/18/2016 11:05 AM, Schrempf Frieder wrote: > On 04.02.2016 12:28, Marek Vasut wrote: >> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >>> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut<marex@denx.de> wrote: >>>>> On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >>>>>> On 03.02.2016 12:12, Marek Vasut wrote: >>>>>>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>>>>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>>>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut<marex@denx.de> wrote: >>>>>>>>>> In that case, debug time. >>>>>>>>>> >>>>>>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>>>>>> Another suggestion would be to try the 100MB transfer in Linux and >>>>>>>>> see if this works or not. >>>>>>>>> >>>>>>>>> That would help us to narrow down whether this is a hardware or >>>>>>>>> software problem. >>>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>>> common/usb_storage.c >>> This was a really helpful hint! Thank you Sergei! >>> >>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >>> (65535 -> 8191) and this time the transfer works without timeouts. >>> >>> As we have a customer who needs this working as soon as possible my >>> question now is how to properly solve this. >>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >>> errors? Which value to choose? >> Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? > At the moment I have two sticks with the same chip around for which > setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. > Also one of our customers tested a few non-working sticks with this > change and reported, that it fixed it for him. > Here's a list of those devices, but I guess there are a lot more: > > 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash > Drive, VID: 0x090c, PID: 0x1000 > 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 > 3. Newron, VID: 0x8644, PID: 0x800e > 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 > Maybe we need a quirk table then ? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-18 15:32 ` Marek Vasut @ 2016-02-18 17:14 ` Fabio Estevam 2016-02-22 7:03 ` Schrempf Frieder 0 siblings, 1 reply; 52+ messages in thread From: Fabio Estevam @ 2016-02-18 17:14 UTC (permalink / raw) To: u-boot On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote: >> Also one of our customers tested a few non-working sticks with this >> change and reported, that it fixed it for him. >> Here's a list of those devices, but I guess there are a lot more: >> >> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash >> Drive, VID: 0x090c, PID: 0x1000 >> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 >> 3. Newron, VID: 0x8644, PID: 0x800e >> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >> > Maybe we need a quirk table then ? It seems the list of affected devices is unknown. What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? Would this impact the USB transfer rate? Frieder, do you know? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-18 17:14 ` Fabio Estevam @ 2016-02-22 7:03 ` Schrempf Frieder 2016-02-22 17:51 ` Maxime Jayat 0 siblings, 1 reply; 52+ messages in thread From: Schrempf Frieder @ 2016-02-22 7:03 UTC (permalink / raw) To: u-boot On 18.02.2016 18:14, Fabio Estevam wrote: > On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote: > >>> Also one of our customers tested a few non-working sticks with this >>> change and reported, that it fixed it for him. >>> Here's a list of those devices, but I guess there are a lot more: >>> >>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash >>> Drive, VID: 0x090c, PID: 0x1000 >>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 >>> 3. Newron, VID: 0x8644, PID: 0x800e >>> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >>> >> Maybe we need a quirk table then ? > It seems the list of affected devices is unknown. > > What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? > > Would this impact the USB transfer rate? Frieder, do you know? I don't really know. While testing I had the feeling, that the transfer is slightly slower, but I can't tell for sure. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-22 7:03 ` Schrempf Frieder @ 2016-02-22 17:51 ` Maxime Jayat 2016-02-22 17:59 ` Fabio Estevam 0 siblings, 1 reply; 52+ messages in thread From: Maxime Jayat @ 2016-02-22 17:51 UTC (permalink / raw) To: u-boot Le 22/02/2016 08:03, Schrempf Frieder a ?crit : > On 18.02.2016 18:14, Fabio Estevam wrote: >> On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut <marex@denx.de> wrote: >> >>>> Also one of our customers tested a few non-working sticks with this >>>> change and reported, that it fixed it for him. >>>> Here's a list of those devices, but I guess there are a lot more: >>>> >>>> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash >>>> Drive, VID: 0x090c, PID: 0x1000 >>>> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 >>>> 3. Newron, VID: 0x8644, PID: 0x800e >>>> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >>>> >>> Maybe we need a quirk table then ? >> It seems the list of affected devices is unknown. >> >> What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? >> >> Would this impact the USB transfer rate? Frieder, do you know? > I don't really know. While testing I had the feeling, that the transfer > is slightly slower, but I can't tell for sure. > Hello, I was hit by the same problem, where my USB SD card reader would timeout in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK to 32767 fixed the problem but I investigated a little more. I was curious to see what the Linux kernel used, because it had no problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to max_sector in the scsiglue, which is set to 240 blocks per transfer by default, and is tunable via sysfs. There is also a list of unusual devices which needs no higher than 64 blocks per transfer. The linux USB FAQ has a very interesting entry about this which explains the rationale for this value: http://www.linux-usb.org/FAQ.html#i5 FWIW: my USB card reader is 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) I've benchmarked in U-boot the time impact of this change. For reading my 16764395 bytes file: USB_MAX_XFER_BLK Read duration (as reported by U-boot): 64 3578 ms 128 2221 ms 240 1673 ms 32767 1020 ms 65535 974 ms So there is definitely a strong impact for lower values. -- Maxime Jayat ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-22 17:51 ` Maxime Jayat @ 2016-02-22 17:59 ` Fabio Estevam 2016-02-23 6:38 ` Hannes Schmelzer 0 siblings, 1 reply; 52+ messages in thread From: Fabio Estevam @ 2016-02-22 17:59 UTC (permalink / raw) To: u-boot On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> wrote: > Hello, > I was hit by the same problem, where my USB SD card reader would timeout > in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK > to 32767 fixed the problem but I investigated a little more. > I was curious to see what the Linux kernel used, because it had no > problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to > max_sector in the scsiglue, which is set to 240 blocks per transfer by > default, and is tunable via sysfs. > There is also a list of unusual devices which needs no higher than 64 > blocks per transfer. > The linux USB FAQ has a very interesting entry about this which explains > the rationale for this value: > http://www.linux-usb.org/FAQ.html#i5 > > FWIW: my USB card reader is > 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) > > I've benchmarked in U-boot the time impact of this change. > For reading my 16764395 bytes file: > USB_MAX_XFER_BLK Read duration (as reported by U-boot): > 64 3578 ms > 128 2221 ms > 240 1673 ms > 32767 1020 ms > 65535 974 ms > > So there is definitely a strong impact for lower values. Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a performance impact. Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the way to go. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-22 17:59 ` Fabio Estevam @ 2016-02-23 6:38 ` Hannes Schmelzer 2016-02-24 17:43 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Hannes Schmelzer @ 2016-02-23 6:38 UTC (permalink / raw) To: u-boot On 22.02.2016 18:59, Fabio Estevam wrote: > On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> wrote: > >> Hello, >> I was hit by the same problem, where my USB SD card reader would timeout >> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK >> to 32767 fixed the problem but I investigated a little more. >> I was curious to see what the Linux kernel used, because it had no >> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to >> max_sector in the scsiglue, which is set to 240 blocks per transfer by >> default, and is tunable via sysfs. >> There is also a list of unusual devices which needs no higher than 64 >> blocks per transfer. >> The linux USB FAQ has a very interesting entry about this which explains >> the rationale for this value: >> http://www.linux-usb.org/FAQ.html#i5 >> >> FWIW: my USB card reader is >> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) >> >> I've benchmarked in U-boot the time impact of this change. >> For reading my 16764395 bytes file: >> USB_MAX_XFER_BLK Read duration (as reported by U-boot): >> 64 3578 ms >> 128 2221 ms >> 240 1673 ms >> 32767 1020 ms >> 65535 974 ms >> >> So there is definitely a strong impact for lower values. > Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a > performance impact. > > Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the way to go. I have configured a value of 8191 some few weeks ago on my zynq board, there was no negative feedback until yesterday :-( A colleague of mine told me, that his USB-stick doesn't work. I had a look. Vendor: 0x1307 Product 0x0165 Version 1.0 I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work. I'm not the big usb-expert ... but would it be possible to move away from this #define to some variable which is adapted to the lowest value on the bus. Is it possible at all to get to right value out of some register ? regards, Hannes ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-23 6:38 ` Hannes Schmelzer @ 2016-02-24 17:43 ` Marek Vasut 2016-02-25 4:13 ` Simon Glass 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-24 17:43 UTC (permalink / raw) To: u-boot On 02/23/2016 07:38 AM, Hannes Schmelzer wrote: > On 22.02.2016 18:59, Fabio Estevam wrote: >> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> >> wrote: >> >>> Hello, >>> I was hit by the same problem, where my USB SD card reader would timeout >>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK >>> to 32767 fixed the problem but I investigated a little more. >>> I was curious to see what the Linux kernel used, because it had no >>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to >>> max_sector in the scsiglue, which is set to 240 blocks per transfer by >>> default, and is tunable via sysfs. >>> There is also a list of unusual devices which needs no higher than 64 >>> blocks per transfer. >>> The linux USB FAQ has a very interesting entry about this which explains >>> the rationale for this value: >>> http://www.linux-usb.org/FAQ.html#i5 >>> >>> FWIW: my USB card reader is >>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) >>> >>> I've benchmarked in U-boot the time impact of this change. >>> For reading my 16764395 bytes file: >>> USB_MAX_XFER_BLK Read duration (as reported by U-boot): >>> 64 3578 ms >>> 128 2221 ms >>> 240 1673 ms >>> 32767 1020 ms >>> 65535 974 ms >>> >>> So there is definitely a strong impact for lower values. >> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a >> performance impact. >> >> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the >> way to go. > I have configured a value of 8191 some few weeks ago on my zynq board, > there was no negative feedback until yesterday :-( > > A colleague of mine told me, that his USB-stick doesn't work. I had a look. > > Vendor: 0x1307 Product 0x0165 Version 1.0 > I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work. > > I'm not the big usb-expert ... but would it be possible to move away > from this > #define to some variable which is adapted to the lowest value on the bus. > Is it possible at all to get to right value out of some register ? We will probably need a quirk table and for the crappy USB sticks, we will just have to use lower maximum xfer size. I would suggest to add an environment variable, which would allow to override the max xfer size. This would help in case the user had a device, which does need a quirk, but is not yet in a quirk table ; as a temporary work around of course. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-24 17:43 ` Marek Vasut @ 2016-02-25 4:13 ` Simon Glass 2016-02-25 17:56 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Simon Glass @ 2016-02-25 4:13 UTC (permalink / raw) To: u-boot Hi, On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote: > > On 02/23/2016 07:38 AM, Hannes Schmelzer wrote: > > On 22.02.2016 18:59, Fabio Estevam wrote: > >> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> > >> wrote: > >> > >>> Hello, > >>> I was hit by the same problem, where my USB SD card reader would timeout > >>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK > >>> to 32767 fixed the problem but I investigated a little more. > >>> I was curious to see what the Linux kernel used, because it had no > >>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to > >>> max_sector in the scsiglue, which is set to 240 blocks per transfer by > >>> default, and is tunable via sysfs. > >>> There is also a list of unusual devices which needs no higher than 64 > >>> blocks per transfer. > >>> The linux USB FAQ has a very interesting entry about this which explains > >>> the rationale for this value: > >>> http://www.linux-usb.org/FAQ.html#i5 > >>> > >>> FWIW: my USB card reader is > >>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) > >>> > >>> I've benchmarked in U-boot the time impact of this change. > >>> For reading my 16764395 bytes file: > >>> USB_MAX_XFER_BLK Read duration (as reported by U-boot): > >>> 64 3578 ms > >>> 128 2221 ms > >>> 240 1673 ms > >>> 32767 1020 ms > >>> 65535 974 ms > >>> > >>> So there is definitely a strong impact for lower values. > >> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a > >> performance impact. > >> > >> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the > >> way to go. > > I have configured a value of 8191 some few weeks ago on my zynq board, > > there was no negative feedback until yesterday :-( > > > > A colleague of mine told me, that his USB-stick doesn't work. I had a look. > > > > Vendor: 0x1307 Product 0x0165 Version 1.0 > > I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work. > > > > I'm not the big usb-expert ... but would it be possible to move away > > from this > > #define to some variable which is adapted to the lowest value on the bus. > > Is it possible at all to get to right value out of some register ? > > We will probably need a quirk table and for the crappy USB sticks, we > will just have to use lower maximum xfer size. I would suggest to add > an environment variable, which would allow to override the max xfer > size. This would help in case the user had a device, which does need > a quirk, but is not yet in a quirk table ; as a temporary work around of > course. Yes. Even better if we can print a message telling the user about this when we detect this error. Regards. Simon ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-25 4:13 ` Simon Glass @ 2016-02-25 17:56 ` Marek Vasut 2016-02-26 1:56 ` Simon Glass 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-02-25 17:56 UTC (permalink / raw) To: u-boot On 02/25/2016 05:13 AM, Simon Glass wrote: > Hi, > > On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote: >> >> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote: >>> On 22.02.2016 18:59, Fabio Estevam wrote: >>>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> I was hit by the same problem, where my USB SD card reader would timeout >>>>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK >>>>> to 32767 fixed the problem but I investigated a little more. >>>>> I was curious to see what the Linux kernel used, because it had no >>>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to >>>>> max_sector in the scsiglue, which is set to 240 blocks per transfer by >>>>> default, and is tunable via sysfs. >>>>> There is also a list of unusual devices which needs no higher than 64 >>>>> blocks per transfer. >>>>> The linux USB FAQ has a very interesting entry about this which explains >>>>> the rationale for this value: >>>>> http://www.linux-usb.org/FAQ.html#i5 >>>>> >>>>> FWIW: my USB card reader is >>>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) >>>>> >>>>> I've benchmarked in U-boot the time impact of this change. >>>>> For reading my 16764395 bytes file: >>>>> USB_MAX_XFER_BLK Read duration (as reported by U-boot): >>>>> 64 3578 ms >>>>> 128 2221 ms >>>>> 240 1673 ms >>>>> 32767 1020 ms >>>>> 65535 974 ms >>>>> >>>>> So there is definitely a strong impact for lower values. >>>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a >>>> performance impact. >>>> >>>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the >>>> way to go. >>> I have configured a value of 8191 some few weeks ago on my zynq board, >>> there was no negative feedback until yesterday :-( >>> >>> A colleague of mine told me, that his USB-stick doesn't work. I had a look. >>> >>> Vendor: 0x1307 Product 0x0165 Version 1.0 >>> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work. >>> >>> I'm not the big usb-expert ... but would it be possible to move away >>> from this >>> #define to some variable which is adapted to the lowest value on the bus. >>> Is it possible at all to get to right value out of some register ? >> >> We will probably need a quirk table and for the crappy USB sticks, we >> will just have to use lower maximum xfer size. I would suggest to add >> an environment variable, which would allow to override the max xfer >> size. This would help in case the user had a device, which does need >> a quirk, but is not yet in a quirk table ; as a temporary work around of >> course. > > Yes. > > Even better if we can print a message telling the user about this when > we detect this error. Agreed. Can you prepare such patch please ? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-25 17:56 ` Marek Vasut @ 2016-02-26 1:56 ` Simon Glass 0 siblings, 0 replies; 52+ messages in thread From: Simon Glass @ 2016-02-26 1:56 UTC (permalink / raw) To: u-boot Hi Marek, On 25 February 2016 at 10:56, Marek Vasut <marex@denx.de> wrote: > On 02/25/2016 05:13 AM, Simon Glass wrote: >> Hi, >> >> On 24 February 2016 at 10:43, Marek Vasut <marex@denx.de> wrote: >>> >>> On 02/23/2016 07:38 AM, Hannes Schmelzer wrote: >>>> On 22.02.2016 18:59, Fabio Estevam wrote: >>>>> On Mon, Feb 22, 2016 at 2:51 PM, Maxime Jayat <jayatmaxime@gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> I was hit by the same problem, where my USB SD card reader would timeout >>>>>> in U-boot when reading a large file (16 MB). Changing USB_MAX_XFER_BLK >>>>>> to 32767 fixed the problem but I investigated a little more. >>>>>> I was curious to see what the Linux kernel used, because it had no >>>>>> problem reading the file. In Linux, USB_MAX_XFER_BLK corresponds to >>>>>> max_sector in the scsiglue, which is set to 240 blocks per transfer by >>>>>> default, and is tunable via sysfs. >>>>>> There is also a list of unusual devices which needs no higher than 64 >>>>>> blocks per transfer. >>>>>> The linux USB FAQ has a very interesting entry about this which explains >>>>>> the rationale for this value: >>>>>> http://www.linux-usb.org/FAQ.html#i5 >>>>>> >>>>>> FWIW: my USB card reader is >>>>>> 0bda:0119 Realtek Semiconductor Corp. Storage Device (SD card reader) >>>>>> >>>>>> I've benchmarked in U-boot the time impact of this change. >>>>>> For reading my 16764395 bytes file: >>>>>> USB_MAX_XFER_BLK Read duration (as reported by U-boot): >>>>>> 64 3578 ms >>>>>> 128 2221 ms >>>>>> 240 1673 ms >>>>>> 32767 1020 ms >>>>>> 65535 974 ms >>>>>> >>>>>> So there is definitely a strong impact for lower values. >>>>> Ok, so with a USB_MAX_XFER_BLK size of 32767 there is not so much of a >>>>> performance impact. >>>>> >>>>> Looks like that changing USB_MAX_XFER_BLK from 65535 to 32767 is the >>>>> way to go. >>>> I have configured a value of 8191 some few weeks ago on my zynq board, >>>> there was no negative feedback until yesterday :-( >>>> >>>> A colleague of mine told me, that his USB-stick doesn't work. I had a look. >>>> >>>> Vendor: 0x1307 Product 0x0165 Version 1.0 >>>> I had to reduce the USB_MAX_XFER_BLK downto 2048 to make it work. >>>> >>>> I'm not the big usb-expert ... but would it be possible to move away >>>> from this >>>> #define to some variable which is adapted to the lowest value on the bus. >>>> Is it possible at all to get to right value out of some register ? >>> >>> We will probably need a quirk table and for the crappy USB sticks, we >>> will just have to use lower maximum xfer size. I would suggest to add >>> an environment variable, which would allow to override the max xfer >>> size. This would help in case the user had a device, which does need >>> a quirk, but is not yet in a quirk table ; as a temporary work around of >>> course. >> >> Yes. >> >> Even better if we can print a message telling the user about this when >> we detect this error. > > Agreed. Can you prepare such patch please ? > Let me put it in my queue and think about it...no promises. Regards, Simon ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-18 10:05 ` Schrempf Frieder 2016-02-18 15:32 ` Marek Vasut @ 2016-04-14 13:20 ` Diego 2016-04-15 10:53 ` Marek Vasut 1 sibling, 1 reply; 52+ messages in thread From: Diego @ 2016-04-14 13:20 UTC (permalink / raw) To: u-boot On 18.02.2016, Schrempf Frieder wrote: > At the moment I have two sticks with the same chip around for which > setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. > Also one of our customers tested a few non-working sticks with this > change and reported, that it fixed it for him. Hi all, sorry for reopening this thread, but I'd like to provide some additional infos. I was experiencing the same problem with several USB thumb drives, especially with some Kingston DataTraveler. Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed out on TD" but also fixed a more subtle problem. Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0": ID 0951:1666 Kingston Technology DataTraveler G4 I was experiencing apparently successful "load" transfers, but the data loaded was actually corrupted when loaded in memory, as a subsequent gzwrite reported broken CRC. U-Boot > usb dev 0 USB device 0: Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0 Type: Removable Hard Disk Capacity: 15004.3 MB = 14.6 GB (30728832 x 512) ... is now current device U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz reading my-image.sdcard.gz 112364153 bytes read in 3306 ms (32.4 MiB/s) U-Boot > gzwrite mmc 1 0x10008000 $filesize Error: inflate() returned -3 uncompressed 4194304 of 2218786816 crcs == 0xa85fe71c/0xd0244792 The decrease of USB_MAX_XFER_BLK from 65535 to 32767 fixed also that "corrupted load" problem, so from what I experienced 32767 is a much more practical and "real life" reliable value. If, as Fabio Estevam suggested, changing USB_MAX_XFER_BLK to 32767 is being considered, I definitely vote for it. Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-14 13:20 ` Diego @ 2016-04-15 10:53 ` Marek Vasut 2016-04-15 12:13 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-04-15 10:53 UTC (permalink / raw) To: u-boot On 04/14/2016 03:20 PM, Diego wrote: > On 18.02.2016, Schrempf Frieder wrote: >> At the moment I have two sticks with the same chip around for which >> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. >> Also one of our customers tested a few non-working sticks with this >> change and reported, that it fixed it for him. > > Hi all, > > sorry for reopening this thread, but I'd like to provide some additional > infos. > > I was experiencing the same problem with several USB thumb drives, especially > with some Kingston DataTraveler. > > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed > out on TD" but also fixed a more subtle problem. So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look into that one stick deeper, that's real bad. > Additionally, on a Kingston DataTraveler labelled "DTSE9 G2 USB 3.0": > ID 0951:1666 Kingston Technology DataTraveler G4 > I was experiencing apparently successful "load" transfers, but the data loaded > was actually corrupted when loaded in memory, as a subsequent gzwrite reported > broken CRC. > > U-Boot > usb dev 0 > > USB device 0: > Device 0: Vendor: Kingston Rev: PMAP Prod: DataTraveler 3.0 > Type: Removable Hard Disk > Capacity: 15004.3 MB = 14.6 GB (30728832 x 512) > ... is now current device > U-Boot > load usb 0:1 0x10008000 my-image.sdcard.gz > reading my-image.sdcard.gz > 112364153 bytes read in 3306 ms (32.4 MiB/s) > U-Boot > gzwrite mmc 1 0x10008000 $filesize > Error: inflate() returned -3 > > uncompressed 4194304 of 2218786816 > crcs == 0xa85fe71c/0xd0244792 > > > The decrease of USB_MAX_XFER_BLK from 65535 to 32767 fixed also that "corrupted > load" problem, so from what I experienced 32767 is a much more practical and > "real life" reliable value. > > If, as Fabio Estevam suggested, changing USB_MAX_XFER_BLK to 32767 is being > considered, I definitely vote for it. > > Bests, > Diego > > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-15 10:53 ` Marek Vasut @ 2016-04-15 12:13 ` Diego 2016-04-18 23:54 ` Marek Vasut 2016-04-27 2:14 ` Marek Vasut 0 siblings, 2 replies; 52+ messages in thread From: Diego @ 2016-04-15 12:13 UTC (permalink / raw) To: u-boot In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto: > On 04/14/2016 03:20 PM, Diego wrote: > > On 18.02.2016, Schrempf Frieder wrote: > >> At the moment I have two sticks with the same chip around for which > >> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. > >> Also one of our customers tested a few non-working sticks with this > >> change and reported, that it fixed it for him. > > > > Hi all, > > > > sorry for reopening this thread, but I'd like to provide some additional > > infos. > > > > I was experiencing the same problem with several USB thumb drives, > > especially with some Kingston DataTraveler. > > > > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI > > timed out on TD" but also fixed a more subtle problem. > > So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look > into that one stick deeper, that's real bad. > Hi Marek, yes, I was getting the following error with the Kingston DTSE9 USB 2.0: EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 The model is the one in this photo: http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg ID 0951:1689 Kingston Technology DataTraveler SE9 I'm available if you want any additional info. Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-15 12:13 ` Diego @ 2016-04-18 23:54 ` Marek Vasut 2016-04-25 8:16 ` Stefan Roese 2016-04-27 2:14 ` Marek Vasut 1 sibling, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-04-18 23:54 UTC (permalink / raw) To: u-boot On 04/15/2016 02:13 PM, Diego wrote: > In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto: >> On 04/14/2016 03:20 PM, Diego wrote: >>> On 18.02.2016, Schrempf Frieder wrote: >>>> At the moment I have two sticks with the same chip around for which >>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. >>>> Also one of our customers tested a few non-working sticks with this >>>> change and reported, that it fixed it for him. >>> >>> Hi all, >>> >>> sorry for reopening this thread, but I'd like to provide some additional >>> infos. >>> >>> I was experiencing the same problem with several USB thumb drives, >>> especially with some Kingston DataTraveler. >>> >>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI >>> timed out on TD" but also fixed a more subtle problem. >> >> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look >> into that one stick deeper, that's real bad. >> > > Hi Marek, > > yes, I was getting the following error with the Kingston DTSE9 USB 2.0: > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > The model is the one in this photo: > http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg > ID 0951:1689 Kingston Technology DataTraveler SE9 > > I'm available if you want any additional info. I have the same stick and the same problems, but I should be able to check it with USB analyzer this or next week. -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-18 23:54 ` Marek Vasut @ 2016-04-25 8:16 ` Stefan Roese 0 siblings, 0 replies; 52+ messages in thread From: Stefan Roese @ 2016-04-25 8:16 UTC (permalink / raw) To: u-boot Hi Marek, On 19.04.2016 01:54, Marek Vasut wrote: > On 04/15/2016 02:13 PM, Diego wrote: >> In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto: >>> On 04/14/2016 03:20 PM, Diego wrote: >>>> On 18.02.2016, Schrempf Frieder wrote: >>>>> At the moment I have two sticks with the same chip around for which >>>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. >>>>> Also one of our customers tested a few non-working sticks with this >>>>> change and reported, that it fixed it for him. >>>> >>>> Hi all, >>>> >>>> sorry for reopening this thread, but I'd like to provide some additional >>>> infos. >>>> >>>> I was experiencing the same problem with several USB thumb drives, >>>> especially with some Kingston DataTraveler. >>>> >>>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI >>>> timed out on TD" but also fixed a more subtle problem. >>> >>> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look >>> into that one stick deeper, that's real bad. >>> >> >> Hi Marek, >> >> yes, I was getting the following error with the Kingston DTSE9 USB 2.0: >> EHCI timed out on TD - token=0x1e008d80 >> EHCI timed out on TD - token=0x1e008d80 >> EHCI timed out on TD - token=0x1e008d80 >> The model is the one in this photo: >> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg >> ID 0951:1689 Kingston Technology DataTraveler SE9 >> >> I'm available if you want any additional info. > > I have the same stick and the same problems, but I should be able to > check it with USB analyzer this or next week. I'm now finally starting to debug this USB key detection problem on SoCFPGA, introduced with my USB scanning speedup patchset. My current configuration is the SoCrates board with an USB OTG cable to attach an USB stick. This is what I get with the later U-Boot (master branch) and this patch reverted (c998da0d67 "usb: Change power-on / scanning timeout handling": => usb start starting USB... USB0: Core Release: 2.93a dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! scanning bus 0 for devices... 1 USB Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) U-Boot Root Hub This does not change if this patch above is reverted or not. Does anyone else have these dwc core timeouts? Thanks, Stefan ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-15 12:13 ` Diego 2016-04-18 23:54 ` Marek Vasut @ 2016-04-27 2:14 ` Marek Vasut 2016-04-27 9:04 ` Diego 1 sibling, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-04-27 2:14 UTC (permalink / raw) To: u-boot On 04/15/2016 02:13 PM, Diego wrote: > In data venerd? 15 aprile 2016 12:53:36, Marek Vasut ha scritto: >> On 04/14/2016 03:20 PM, Diego wrote: >>> On 18.02.2016, Schrempf Frieder wrote: >>>> At the moment I have two sticks with the same chip around for which >>>> setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. >>>> Also one of our customers tested a few non-working sticks with this >>>> change and reported, that it fixed it for him. >>> >>> Hi all, >>> >>> sorry for reopening this thread, but I'd like to provide some additional >>> infos. >>> >>> I was experiencing the same problem with several USB thumb drives, >>> especially with some Kingston DataTraveler. >>> >>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI >>> timed out on TD" but also fixed a more subtle problem. >> >> So the DTSE9 is problematic even on EHCI ? Sigh ... I'll have to look >> into that one stick deeper, that's real bad. >> > > Hi Marek, > > yes, I was getting the following error with the Kingston DTSE9 USB 2.0: > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > The model is the one in this photo: > http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg > ID 0951:1689 Kingston Technology DataTraveler SE9 > > I'm available if you want any additional info. This Kingston DTSE9 seems to be really pure evil. I connected it to TotalPhase Beagle USB 480 and plugged it into a PC and the bloody stick generates broken packets at the beginning. I suspect this is so bad that it crashes DWC2 controller if plugged directly into it. I didn't try investigating it with another EHCI controller yet. Which CPU do you use on your system? > Bests, > Diego > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-27 2:14 ` Marek Vasut @ 2016-04-27 9:04 ` Diego 2016-04-27 16:13 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-04-27 9:04 UTC (permalink / raw) To: u-boot Il 27 aprile 2016 04:14:45 CEST, Marek Vasut <marex@denx.de> ha scritto: >On 04/15/2016 02:13 PM, Diego wrote: >> >> Hi Marek, >> >> yes, I was getting the following error with the Kingston DTSE9 USB >2.0: >> EHCI timed out on TD - token=0x1e008d80 >> EHCI timed out on TD - token=0x1e008d80 >> EHCI timed out on TD - token=0x1e008d80 >> The model is the one in this photo: >> >http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg >> ID 0951:1689 Kingston Technology DataTraveler SE9 >> >> I'm available if you want any additional info. > >This Kingston DTSE9 seems to be really pure evil. I connected it to >TotalPhase Beagle USB 480 and plugged it into a PC and the bloody >stick generates broken packets at the beginning. I suspect this is >so bad that it crashes DWC2 controller if plugged directly into it. > >I didn't try investigating it with another EHCI controller yet. >Which CPU do you use on your system? > Hi Marek, I'm using a Boundary Devices Nitrogen6x with Freescale / NXP i.MX6Q SOC. Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-27 9:04 ` Diego @ 2016-04-27 16:13 ` Marek Vasut 2016-04-28 13:04 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-04-27 16:13 UTC (permalink / raw) To: u-boot On 04/27/2016 11:04 AM, Diego wrote: > > > Il 27 aprile 2016 04:14:45 CEST, Marek Vasut <marex@denx.de> ha scritto: >> On 04/15/2016 02:13 PM, Diego wrote: >>> >>> Hi Marek, >>> >>> yes, I was getting the following error with the Kingston DTSE9 USB >> 2.0: >>> EHCI timed out on TD - token=0x1e008d80 >>> EHCI timed out on TD - token=0x1e008d80 >>> EHCI timed out on TD - token=0x1e008d80 >>> The model is the one in this photo: >>> >> http://katteway.com/images/Kingston-DataTraveler-DTSE9-8GB-USB-Flash-Drive-Silver.jpg >>> ID 0951:1689 Kingston Technology DataTraveler SE9 >>> >>> I'm available if you want any additional info. >> >> This Kingston DTSE9 seems to be really pure evil. I connected it to >> TotalPhase Beagle USB 480 and plugged it into a PC and the bloody >> stick generates broken packets at the beginning. I suspect this is >> so bad that it crashes DWC2 controller if plugged directly into it. >> >> I didn't try investigating it with another EHCI controller yet. >> Which CPU do you use on your system? >> > > Hi Marek, > > I'm using a Boundary Devices Nitrogen6x with Freescale / NXP i.MX6Q SOC. OK, I have to two identical sticks and neither has the same USB ID as yours. Can you do lsusb -vvv -d 0951:1689 ? -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-27 16:13 ` Marek Vasut @ 2016-04-28 13:04 ` Diego 2016-04-28 22:49 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-04-28 13:04 UTC (permalink / raw) To: u-boot In data mercoled? 27 aprile 2016 18:13:51, Marek Vasut ha scritto: > > OK, I have to two identical sticks and neither has the same USB ID as > yours. Can you do lsusb -vvv -d 0951:1689 ? Hi Marek, thanks for taking the time to look into this. Here you are: # lsusb -vvv -d 0951:1689 Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0951 Kingston Technology idProduct 0x1689 DataTraveler SE9 bcdDevice 1.00 iManufacturer 1 Kingston iProduct 2 DataTraveler SE9 iSerial 3 0019E06B084BFD10470133E8 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered) Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-28 13:04 ` Diego @ 2016-04-28 22:49 ` Marek Vasut 2016-04-29 7:58 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-04-28 22:49 UTC (permalink / raw) To: u-boot On 04/28/2016 03:04 PM, Diego wrote: > In data mercoled? 27 aprile 2016 18:13:51, Marek Vasut ha scritto: >> >> OK, I have to two identical sticks and neither has the same USB ID as >> yours. Can you do lsusb -vvv -d 0951:1689 ? > > Hi Marek, > > thanks for taking the time to look into this. > Here you are: > # lsusb -vvv -d 0951:1689 > > Bus 003 Device 020: ID 0951:1689 Kingston Technology DataTraveler SE9 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0951 Kingston Technology > idProduct 0x1689 DataTraveler SE9 > bcdDevice 1.00 > iManufacturer 1 Kingston > iProduct 2 DataTraveler SE9 > iSerial 3 0019E06B084BFD10470133E8 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 80 Bulk-Only > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 255 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 255 > Device Qualifier (for other device speed): > bLength 10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > bNumConfigurations 1 > can't get debug descriptor: Resource temporarily unavailable > Device Status: 0x0000 > (Bus Powered) Urgh, so you seem to have third revision of this stick. I have two sticks which are exactly the same and work in U-Boot on MX6 wandboard: => usb reset resetting USB... USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Mass Storage, USB Revision 2.0 - Kingston DataTraveler 2.0 C86000BDB6FFB0201A35968E - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0930 Product 0x6545 Version 1.16 Configuration: 1 - Interfaces: 1 Bus Powered 300mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 => usb reset resetting USB... EHCI failed to shut down host controller. USB0: Port not available. USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Mass Storage, USB Revision 2.0 - Kingston DataTraveler 2.0 001A4D5F1A5C1010B9445765 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0951 Product 0x1665 Version 2.0 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-28 22:49 ` Marek Vasut @ 2016-04-29 7:58 ` Diego 2016-05-03 21:01 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-04-29 7:58 UTC (permalink / raw) To: u-boot In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto: > > Urgh, so you seem to have third revision of this stick. I have two > sticks which are exactly the same and work in U-Boot on MX6 wandboard: > Hi Marek, how big is the file you're trying to load? For me it fails for files bigger than 16MB: U-Boot > usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0424 Product 0x2513 Version 11.179 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Mass Storage, USB Revision 2.0 - Kingston DataTraveler SE9 0019E06B084BFD10470133E8 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0951 Product 0x1689 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 U-Boot > load usb 0:1 0x10008000 file1.raw reading file1.raw 1048576 bytes read in 59 ms (16.9 MiB/s) U-Boot > load usb 0:1 0x10008000 file2.raw reading file2.raw 2097152 bytes read in 102 ms (19.6 MiB/s) U-Boot > load usb 0:1 0x10008000 file4.raw reading file4.raw 4194304 bytes read in 175 ms (22.9 MiB/s) U-Boot > load usb 0:1 0x10008000 file6.raw reading file6.raw 6291456 bytes read in 255 ms (23.5 MiB/s) U-Boot > load usb 0:1 0x10008000 file8.raw reading file8.raw 8388608 bytes read in 334 ms (24 MiB/s) U-Boot > load usb 0:1 0x10008000 file10.raw reading file10.raw 10485760 bytes read in 408 ms (24.5 MiB/s) U-Boot > load usb 0:1 0x10008000 file15.raw reading file15.raw 15728640 bytes read in 603 ms (24.9 MiB/s) U-Boot > load usb 0:1 0x10008000 file16.raw reading file16.raw EHCI timed out on TD - token=0x90008d80 EHCI timed out on TD - token=0x10008d80 EHCI timed out on TD - token=0x10008d80 Error reading cluster ** Unable to read file file16.raw ** U-Boot > load usb 0:1 0x10008000 file20.raw reading file20.raw EHCI timed out on TD - token=0xd0008d80 EHCI timed out on TD - token=0x50008d80 EHCI timed out on TD - token=0x50008d80 Error reading cluster ** Unable to read file file20.raw ** U-Boot > load usb 0:1 0x10008000 file40.raw reading file40.raw EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 Error reading cluster ** Unable to read file file40.raw ** U-Boot > Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-04-29 7:58 ` Diego @ 2016-05-03 21:01 ` Marek Vasut 2016-05-04 9:13 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-05-03 21:01 UTC (permalink / raw) To: u-boot On 04/29/2016 09:58 AM, Diego wrote: > In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto: >> >> Urgh, so you seem to have third revision of this stick. I have two >> sticks which are exactly the same and work in U-Boot on MX6 wandboard: >> > > Hi Marek, > > how big is the file you're trying to load? > For me it fails for files bigger than 16MB: Ha ok, I see it now. According to the bus analyzer, the stick Acks long block transfer, but then just times out, I guess because it prepares the data or something. Just a dummy question, did you try reducing USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. > U-Boot > usb info > 1: Hub, USB Revision 2.0 > - u-boot EHCI Host Controller > - Class: Hub > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0000 Product 0x0000 Version 1.0 > Configuration: 1 > - Interfaces: 1 Self Powered 0mA > Interface: 0 > - Alternate Setting 0, Endpoints: 1 > - Class Hub > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > 2: Hub, USB Revision 2.0 > - Class: Hub > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0424 Product 0x2513 Version 11.179 > Configuration: 1 > - Interfaces: 1 Self Powered Remote Wakeup 2mA > Interface: 0 > - Alternate Setting 0, Endpoints: 1 > - Class Hub > - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms > - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms > > 3: Mass Storage, USB Revision 2.0 > - Kingston DataTraveler SE9 0019E06B084BFD10470133E8 > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0951 Product 0x1689 Version 1.0 > Configuration: 1 > - Interfaces: 1 Bus Powered 100mA > Interface: 0 > - Alternate Setting 0, Endpoints: 2 > - Class Mass Storage, Transp. SCSI, Bulk only > - Endpoint 1 In Bulk MaxPacket 512 > - Endpoint 2 Out Bulk MaxPacket 512 > > U-Boot > load usb 0:1 0x10008000 file1.raw > reading file1.raw > 1048576 bytes read in 59 ms (16.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file2.raw > reading file2.raw > 2097152 bytes read in 102 ms (19.6 MiB/s) > U-Boot > load usb 0:1 0x10008000 file4.raw > reading file4.raw > 4194304 bytes read in 175 ms (22.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file6.raw > reading file6.raw > 6291456 bytes read in 255 ms (23.5 MiB/s) > U-Boot > load usb 0:1 0x10008000 file8.raw > reading file8.raw > 8388608 bytes read in 334 ms (24 MiB/s) > U-Boot > load usb 0:1 0x10008000 file10.raw > reading file10.raw > 10485760 bytes read in 408 ms (24.5 MiB/s) > U-Boot > load usb 0:1 0x10008000 file15.raw > reading file15.raw > 15728640 bytes read in 603 ms (24.9 MiB/s) > U-Boot > load usb 0:1 0x10008000 file16.raw > reading file16.raw > EHCI timed out on TD - token=0x90008d80 > EHCI timed out on TD - token=0x10008d80 > EHCI timed out on TD - token=0x10008d80 > Error reading cluster > ** Unable to read file file16.raw ** > U-Boot > load usb 0:1 0x10008000 file20.raw > reading file20.raw > EHCI timed out on TD - token=0xd0008d80 > EHCI timed out on TD - token=0x50008d80 > EHCI timed out on TD - token=0x50008d80 > Error reading cluster > ** Unable to read file file20.raw ** > U-Boot > load usb 0:1 0x10008000 file40.raw > reading file40.raw > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > EHCI timed out on TD - token=0x1e008d80 > Error reading cluster > ** Unable to read file file40.raw ** > U-Boot > > > Bests, > Diego > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-03 21:01 ` Marek Vasut @ 2016-05-04 9:13 ` Diego 2016-05-04 11:45 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-05-04 9:13 UTC (permalink / raw) To: u-boot In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto: > On 04/29/2016 09:58 AM, Diego wrote: > > In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto: > >> Urgh, so you seem to have third revision of this stick. I have two > > > >> sticks which are exactly the same and work in U-Boot on MX6 wandboard: > > Hi Marek, > > > > how big is the file you're trying to load? > > > > For me it fails for files bigger than 16MB: > > Ha ok, I see it now. According to the bus analyzer, the stick Acks long > block transfer, but then just times out, I guess because it prepares the > data or something. Just a dummy question, did you try reducing > USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. > Hi Marek, that was the original argument of my mail thread: http://lists.denx.de/pipermail/u-boot/2016-April/251799.html Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed out on TD". I was questioning what was the best approach to fix the problem. It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my experience, my coworker's experience, and previous mails in this same thread, I'd guess something like 50% or lower work with 65535, while something like 90% or more work with 32767. http://lists.denx.de/pipermail/u-boot/2016-February/245893.html So I see three options: 1) 65535 default with quirk table 2) 32767 default without quirk table 3) 32767 default with quirk table Personally I think 3) would be the safest solution, but I think 2) would at least work for most thumb drives. As the transfer speed wouldn't be affected much for 32767: http://lists.denx.de/pipermail/u-boot/2016-February/246267.html and as the quirk table for 65535 would grow quite a lot with time, I think. Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-04 9:13 ` Diego @ 2016-05-04 11:45 ` Marek Vasut 2016-05-04 14:06 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-05-04 11:45 UTC (permalink / raw) To: u-boot On 05/04/2016 11:13 AM, Diego wrote: > In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto: >> On 04/29/2016 09:58 AM, Diego wrote: >>> In data venerd? 29 aprile 2016 00:49:22, Marek Vasut ha scritto: >>>> Urgh, so you seem to have third revision of this stick. I have two >>> >>>> sticks which are exactly the same and work in U-Boot on MX6 wandboard: >>> Hi Marek, >>> >>> how big is the file you're trying to load? >>> >>> For me it fails for files bigger than 16MB: >> >> Ha ok, I see it now. According to the bus analyzer, the stick Acks long >> block transfer, but then just times out, I guess because it prepares the >> data or something. Just a dummy question, did you try reducing >> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. >> > > Hi Marek, > > that was the original argument of my mail thread: > http://lists.denx.de/pipermail/u-boot/2016-April/251799.html > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI timed > out on TD". > > I was questioning what was the best approach to fix the problem. > It seems that 65536 doesn't work for quite some USB thumb drives. Seeing my > experience, my coworker's experience, and previous mails in this same thread, > I'd guess something like 50% or lower work with 65535, while something like > 90% or more work with 32767. > http://lists.denx.de/pipermail/u-boot/2016-February/245893.html > > So I see three options: > 1) 65535 default with quirk table > 2) 32767 default without quirk table > 3) 32767 default with quirk table > > Personally I think 3) would be the safest solution, but I think 2) would at > least work for most thumb drives. 1) with the quirk table would be the way to go, modern(ish) drives should work fine with 65535 . > As the transfer speed wouldn't be affected much for 32767: > http://lists.denx.de/pipermail/u-boot/2016-February/246267.html > and as the quirk table for 65535 would grow quite a lot with time, I think. Yeah, but with old drives only, which I think is soon gonna be moot. > Bests, > Diego > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-04 11:45 ` Marek Vasut @ 2016-05-04 14:06 ` Diego 2016-05-04 21:36 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-05-04 14:06 UTC (permalink / raw) To: u-boot In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: > On 05/04/2016 11:13 AM, Diego wrote: > > In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto: > >> On 04/29/2016 09:58 AM, Diego wrote: > >>> For me it fails for files bigger than 16MB: > >> Ha ok, I see it now. According to the bus analyzer, the stick Acks long > >> block transfer, but then just times out, I guess because it prepares the > >> data or something. Just a dummy question, did you try reducing > >> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. > > > > Hi Marek, > > > > that was the original argument of my mail thread: > > http://lists.denx.de/pipermail/u-boot/2016-April/251799.html > > Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI > > timed out on TD". > > > > I was questioning what was the best approach to fix the problem. > > It seems that 65536 doesn't work for quite some USB thumb drives. Seeing > > my > > experience, my coworker's experience, and previous mails in this same > > thread, I'd guess something like 50% or lower work with 65535, while > > something like 90% or more work with 32767. > > http://lists.denx.de/pipermail/u-boot/2016-February/245893.html > > > > So I see three options: > > 1) 65535 default with quirk table > > 2) 32767 default without quirk table > > 3) 32767 default with quirk table > > > > Personally I think 3) would be the safest solution, but I think 2) would > > at > > least work for most thumb drives. > > 1) with the quirk table would be the way to go, modern(ish) drives > should work fine with 65535 . > I personally can't see any improvement with more recent thumb drives, quite the opposite. WORKING WITH 65535: - ancient Sandisk 256MB ID 0781:5151 SanDisk Corp. Cruzer Micro Flash Drive - old Sony 8GB ID 054c:0243 Sony Corp. MicroVault Flash Drive - recent Kingston DT101 G2 16GB ID 0951:1642 Kingston Technology DT101 G2 NOT WORKING WITH 65535: - recent Kingston G3 16GB ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB - new Kingston USB 2.0 8GB ID 0951:1689 Kingston Technology DataTraveler SE9 - brand new Kingston G2 16GB / 32GB USB 3.0 ID 0951:1666 Kingston Technology DataTraveler G4 Why are you saying modern(ish) drives should work? For others following the thread, please post your experience, especially with more recent drives (remember to test with files >16MB). Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-04 14:06 ` Diego @ 2016-05-04 21:36 ` Marek Vasut 2016-05-10 12:04 ` Diego 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-05-04 21:36 UTC (permalink / raw) To: u-boot On 05/04/2016 04:06 PM, Diego wrote: > In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: >> On 05/04/2016 11:13 AM, Diego wrote: >>> In data marted? 3 maggio 2016 23:01:10, Marek Vasut ha scritto: >>>> On 04/29/2016 09:58 AM, Diego wrote: >>>>> For me it fails for files bigger than 16MB: >>>> Ha ok, I see it now. According to the bus analyzer, the stick Acks long >>>> block transfer, but then just times out, I guess because it prepares the >>>> data or something. Just a dummy question, did you try reducing >>>> USB_MAX_XFER_BLK ? Try with 4096 instead of 65536 , that might work. >>> >>> Hi Marek, >>> >>> that was the original argument of my mail thread: >>> http://lists.denx.de/pipermail/u-boot/2016-April/251799.html >>> Changing USB_MAX_XFER_BLK from 65535 to 32767 definitely fixed the "EHCI >>> timed out on TD". >>> >>> I was questioning what was the best approach to fix the problem. >>> It seems that 65536 doesn't work for quite some USB thumb drives. Seeing >>> my >>> experience, my coworker's experience, and previous mails in this same >>> thread, I'd guess something like 50% or lower work with 65535, while >>> something like 90% or more work with 32767. >>> http://lists.denx.de/pipermail/u-boot/2016-February/245893.html >>> >>> So I see three options: >>> 1) 65535 default with quirk table >>> 2) 32767 default without quirk table >>> 3) 32767 default with quirk table >>> >>> Personally I think 3) would be the safest solution, but I think 2) would >>> at >>> least work for most thumb drives. >> >> 1) with the quirk table would be the way to go, modern(ish) drives >> should work fine with 65535 . >> > > I personally can't see any improvement with more recent thumb drives, quite > the opposite. > WORKING WITH 65535: > - ancient Sandisk 256MB > ID 0781:5151 SanDisk Corp. Cruzer Micro Flash Drive > - old Sony 8GB > ID 054c:0243 Sony Corp. MicroVault Flash Drive > - recent Kingston DT101 G2 16GB > ID 0951:1642 Kingston Technology DT101 G2 > > NOT WORKING WITH 65535: > - recent Kingston G3 16GB > ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB > - new Kingston USB 2.0 8GB > ID 0951:1689 Kingston Technology DataTraveler SE9 > - brand new Kingston G2 16GB / 32GB USB 3.0 > ID 0951:1666 Kingston Technology DataTraveler G4 > > Why are you saying modern(ish) drives should work? Hmmmmm :-( > For others following the thread, please post your experience, especially with > more recent drives (remember to test with files >16MB). I don't think it's really worth doing a thread about which sticks work and which don't. I would find it much more valuable to address this issue properly. I wonder if it would make sense to, instead of starting with a big value which might not work, start with a small(er) value and increase it with each subsequent block transfer. Quite similarly to what TCP does. Would you be willing to look into it ? > Diego > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-04 21:36 ` Marek Vasut @ 2016-05-10 12:04 ` Diego 2016-05-10 12:32 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Diego @ 2016-05-10 12:04 UTC (permalink / raw) To: u-boot In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto: > On 05/04/2016 04:06 PM, Diego wrote: > > In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: > >> On 05/04/2016 11:13 AM, Diego wrote: > >>> <snip> > >>> So I see three options: > >>> 1) 65535 default with quirk table > >>> 2) 32767 default without quirk table > >>> 3) 32767 default with quirk table > >>> > >>> Personally I think 3) would be the safest solution, but I think 2) would > >>> at > >>> least work for most thumb drives. > >> > >> 1) with the quirk table would be the way to go, modern(ish) drives > >> should work fine with 65535 . > > > > I personally can't see any improvement with more recent thumb drives, > > quite the opposite. > > > > <snip> > > Why are you saying modern(ish) drives should work? > > Hmmmmm :-( > > > For others following the thread, please post your experience, especially > > with more recent drives (remember to test with files >16MB). > > I don't think it's really worth doing a thread about which sticks work > and which don't. I would find it much more valuable to address this > issue properly. I wonder if it would make sense to, instead of starting > with a big value which might not work, start with a small(er) value and > increase it with each subsequent block transfer. Quite similarly to what > TCP does. Would you be willing to look into it ? > Hi Marek, so your proposal is to ramp up transferred block size during transfer? What's the rationale behind the proposal? In other words, why do you think it will fix the problem? Regarding implementing your proposal, it might take me very long to find some time to dedicate to it, so if anybody else wants to step up before I look at it, just raise your hand. Bests, Diego ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-10 12:04 ` Diego @ 2016-05-10 12:32 ` Marek Vasut 2016-05-20 5:07 ` Rajesh Bhagat 0 siblings, 1 reply; 52+ messages in thread From: Marek Vasut @ 2016-05-10 12:32 UTC (permalink / raw) To: u-boot On 05/10/2016 02:04 PM, Diego wrote: > In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto: >> On 05/04/2016 04:06 PM, Diego wrote: >>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: >>>> On 05/04/2016 11:13 AM, Diego wrote: >>>>> <snip> >>>>> So I see three options: >>>>> 1) 65535 default with quirk table >>>>> 2) 32767 default without quirk table >>>>> 3) 32767 default with quirk table >>>>> >>>>> Personally I think 3) would be the safest solution, but I think 2) would >>>>> at >>>>> least work for most thumb drives. >>>> >>>> 1) with the quirk table would be the way to go, modern(ish) drives >>>> should work fine with 65535 . >>> >>> I personally can't see any improvement with more recent thumb drives, >>> quite the opposite. >>> >>> <snip> >>> Why are you saying modern(ish) drives should work? >> >> Hmmmmm :-( >> >>> For others following the thread, please post your experience, especially >>> with more recent drives (remember to test with files >16MB). >> >> I don't think it's really worth doing a thread about which sticks work >> and which don't. I would find it much more valuable to address this >> issue properly. I wonder if it would make sense to, instead of starting >> with a big value which might not work, start with a small(er) value and >> increase it with each subsequent block transfer. Quite similarly to what >> TCP does. Would you be willing to look into it ? >> > > Hi Marek, Hi! > so your proposal is to ramp up transferred block size during transfer? > What's the rationale behind the proposal? In other words, why do you think it > will fix the problem? You will get one transfer failure somewhere in the middle and this will let you determine the maximum transfer size for particular stick. > Regarding implementing your proposal, it might take me very long to find some > time to dedicate to it, so if anybody else wants to step up before I look at > it, just raise your hand. OK > Bests, > Diego > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-10 12:32 ` Marek Vasut @ 2016-05-20 5:07 ` Rajesh Bhagat 2016-05-20 11:52 ` Marek Vasut 0 siblings, 1 reply; 52+ messages in thread From: Rajesh Bhagat @ 2016-05-20 5:07 UTC (permalink / raw) To: u-boot > -----Original Message----- > From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut > Sent: Tuesday, May 10, 2016 6:02 PM > To: Diego <diego.ml@zoho.com> > Cc: u-boot at lists.denx.de; Stefan Roese <sr@denx.de> > Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives) > > On 05/10/2016 02:04 PM, Diego wrote: > > In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto: > >> On 05/04/2016 04:06 PM, Diego wrote: > >>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: > >>>> On 05/04/2016 11:13 AM, Diego wrote: > >>>>> <snip> > >>>>> So I see three options: > >>>>> 1) 65535 default with quirk table > >>>>> 2) 32767 default without quirk table > >>>>> 3) 32767 default with quirk table > >>>>> > >>>>> Personally I think 3) would be the safest solution, but I think 2) > >>>>> would at least work for most thumb drives. > >>>> > >>>> 1) with the quirk table would be the way to go, modern(ish) drives > >>>> should work fine with 65535 . > >>> > >>> I personally can't see any improvement with more recent thumb > >>> drives, quite the opposite. > >>> > >>> <snip> > >>> Why are you saying modern(ish) drives should work? > >> > >> Hmmmmm :-( > >> > >>> For others following the thread, please post your experience, > >>> especially with more recent drives (remember to test with files >16MB). > >> > >> I don't think it's really worth doing a thread about which sticks > >> work and which don't. I would find it much more valuable to address > >> this issue properly. I wonder if it would make sense to, instead of > >> starting with a big value which might not work, start with a > >> small(er) value and increase it with each subsequent block transfer. > >> Quite similarly to what TCP does. Would you be willing to look into it ? > >> > > > > Hi Marek, > > Hi! > > > so your proposal is to ramp up transferred block size during transfer? > > What's the rationale behind the proposal? In other words, why do you > > think it will fix the problem? > > You will get one transfer failure somewhere in the middle and this will let you > determine the maximum transfer size for particular stick. > > > Regarding implementing your proposal, it might take me very long to > > find some time to dedicate to it, so if anybody else wants to step up > > before I look at it, just raise your hand. > > OK > Hello Marek, I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to focus on this value and is not impacted, kept the value so low i.e. 20? #ifdef CONFIG_USB_EHCI /* * The U-Boot EHCI driver can handle any transfer length as long as there is * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are * limited to 65535 blocks. */ #define USB_MAX_XFER_BLK 65535 #else #define USB_MAX_XFER_BLK 20 #endif Common code suggests it is used in same way as used in EHCI. Please comment. Best Regards, Rajesh Bhagat > > Bests, > > Diego > > > > > -- > Best regards, > Marek Vasut > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-05-20 5:07 ` Rajesh Bhagat @ 2016-05-20 11:52 ` Marek Vasut 0 siblings, 0 replies; 52+ messages in thread From: Marek Vasut @ 2016-05-20 11:52 UTC (permalink / raw) To: u-boot On 05/20/2016 07:07 AM, Rajesh Bhagat wrote: > > >> -----Original Message----- >> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek Vasut >> Sent: Tuesday, May 10, 2016 6:02 PM >> To: Diego <diego.ml@zoho.com> >> Cc: u-boot at lists.denx.de; Stefan Roese <sr@denx.de> >> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives) >> >> On 05/10/2016 02:04 PM, Diego wrote: >>> In data mercoled? 4 maggio 2016 23:36:46, Marek Vasut ha scritto: >>>> On 05/04/2016 04:06 PM, Diego wrote: >>>>> In data mercoled? 4 maggio 2016 13:45:57, Marek Vasut ha scritto: >>>>>> On 05/04/2016 11:13 AM, Diego wrote: >>>>>>> <snip> >>>>>>> So I see three options: >>>>>>> 1) 65535 default with quirk table >>>>>>> 2) 32767 default without quirk table >>>>>>> 3) 32767 default with quirk table >>>>>>> >>>>>>> Personally I think 3) would be the safest solution, but I think 2) >>>>>>> would at least work for most thumb drives. >>>>>> >>>>>> 1) with the quirk table would be the way to go, modern(ish) drives >>>>>> should work fine with 65535 . >>>>> >>>>> I personally can't see any improvement with more recent thumb >>>>> drives, quite the opposite. >>>>> >>>>> <snip> >>>>> Why are you saying modern(ish) drives should work? >>>> >>>> Hmmmmm :-( >>>> >>>>> For others following the thread, please post your experience, >>>>> especially with more recent drives (remember to test with files >16MB). >>>> >>>> I don't think it's really worth doing a thread about which sticks >>>> work and which don't. I would find it much more valuable to address >>>> this issue properly. I wonder if it would make sense to, instead of >>>> starting with a big value which might not work, start with a >>>> small(er) value and increase it with each subsequent block transfer. >>>> Quite similarly to what TCP does. Would you be willing to look into it ? >>>> >>> >>> Hi Marek, >> >> Hi! >> >>> so your proposal is to ramp up transferred block size during transfer? >>> What's the rationale behind the proposal? In other words, why do you >>> think it will fix the problem? >> >> You will get one transfer failure somewhere in the middle and this will let you >> determine the maximum transfer size for particular stick. >> >>> Regarding implementing your proposal, it might take me very long to >>> find some time to dedicate to it, so if anybody else wants to step up >>> before I look at it, just raise your hand. >> >> OK >> > > Hello Marek, > > I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't seem to > focus on this value and is not impacted, kept the value so low i.e. 20? > > #ifdef CONFIG_USB_EHCI > /* > * The U-Boot EHCI driver can handle any transfer length as long as there is > * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are > * limited to 65535 blocks. > */ > #define USB_MAX_XFER_BLK 65535 > #else > #define USB_MAX_XFER_BLK 20 > #endif > > Common code suggests it is used in same way as used in EHCI. Please comment. The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be patches to set it to higher value for XHCI. Feel free to test and send a patch. Thanks Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) 2016-02-03 16:40 ` Marek Vasut 2016-02-03 19:16 ` Sergei Temerkhanov @ 2016-02-04 8:06 ` Schrempf Frieder 1 sibling, 0 replies; 52+ messages in thread From: Schrempf Frieder @ 2016-02-04 8:06 UTC (permalink / raw) To: u-boot On 03.02.2016 17:40, Marek Vasut wrote: > On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >> On 03.02.2016 12:12, Marek Vasut wrote: >>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>>> On 03.02.2016 10:55, Fabio Estevam wrote: >>>>> On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut <marex@denx.de> wrote: >>>>>> In that case, debug time. >>>>>> >>>>>> Usual problems are bad routing of the tracks on the board , so try >>>>>> with USB 1.1 hub and if that works, that's your problem. >>>>> Another suggestion would be to try the 100MB transfer in Linux and see >>>>> if this works or not. >>>>> >>>>> That would help us to narrow down whether this is a hardware or >>>>> software problem. >>>> Thank you Marek and Fabio for your input! >>>> >>>> I tried the file transfer in Linux and this seems to work fine. >>>> Also we have been using this hardware for quite some time, also with USB >>>> mass storage and large files in Linux and I can't remember any problems. >>>> For these reasons I think that the hardware is ok. >>>> >>>> I added the DEBUG defines and here are the lines around one of the >>>> timeouts. With my very limited knowledge of how usb works, I can't read >>>> much from those messages: >>> It'd help if you shared your patch and the whole output. That way we can >>> check if something goes wrong at the beginning. >>> >>> I wonder if we might be facing some misconfiguration of the USB PHY here >>> ? >>> >>> I don't have a MX6Solo . Fabio, any chance you can try ? >> Here is the debug log for "usb reset": http://paste.ubuntu.com/14865306/ >> And here the log for the file transfer (different thumb drive and >> therefore different messages than posted before): >> http://paste.ubuntu.com/14865349/ >> >> The only changes to U-Boot I made is adding my board configuration >> (derived from Freescale SabreSD config). >> The only difference from the SabreSD config related to USB is, that I >> have set CONFIG_USB_MAX_CONTROLLER_COUNT to 2 instead of 1. > The detection seems fine, it even does what it's supposed to do. > > You have a USB hub somewhere in there, right ? Is it a powered one or not ? > > What I find weird in the later log is that the failure always happens when > the buffer is at 0x19fffe00 . I suppose you're loading to 0x18000000 and you > have 0x20000000 or 512MiB of RAM (?). Try loading to 0x8000000 and see if > that helps. If it does, then you might be overwriting some malloc area of > U-Boot or somesuch . We have two self-powered USB hubs on our board, but we also have boards without any hub and I can see the same issue on those. I tried loading to 0x8000000 and the strange thing is, that it even fails on those USB devices, that were previously working while loading to 0x18000000. So reading fails on all USB devices I tried, when loading to 0x8000000 with a log like this: http://paste.ubuntu.com/14875686/ But when I load to 0x18000000 I have 2 devices with 100% success rate: http://paste.ubuntu.com/14875795/ And 1 device with 100% failure rate: http://paste.ubuntu.com/14865349/ I even have 1GiB of RAM on this board. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [U-Boot] Issue with USB mass storage (thumb drives) @ 2016-10-14 9:01 Michael Kasprowicz 0 siblings, 0 replies; 52+ messages in thread From: Michael Kasprowicz @ 2016-10-14 9:01 UTC (permalink / raw) To: u-boot Hi Uboot team, Is this problem of EHCI timed out on TD - token=0x80008d80 already resolved ? If yes can soneone please point me to the solution. I am seeing this read timeout failure with 2 n 4 GB Usb drives. Its a no go for our project, please help or advise. Thanks, Mike ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2016-10-14 9:01 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-02 10:35 [U-Boot] Issue with USB mass storage (thumb drives) Schrempf Frieder 2016-02-02 16:28 ` Fabio Estevam 2016-02-02 16:39 ` Marek Vasut 2016-02-03 7:40 ` Schrempf Frieder 2016-02-03 7:45 ` Hannes Schmelzer 2016-02-03 9:34 ` Marek Vasut 2016-02-03 9:40 ` Marek Vasut 2016-02-03 9:55 ` Fabio Estevam 2016-02-03 10:15 ` Schrempf Frieder 2016-02-03 11:12 ` Marek Vasut 2016-02-03 11:49 ` Schrempf Frieder 2016-02-03 16:40 ` Marek Vasut 2016-02-03 19:16 ` Sergei Temerkhanov 2016-02-04 8:21 ` Schrempf Frieder 2016-02-04 11:28 ` Marek Vasut 2016-02-08 8:41 ` Hannes Schmelzer 2016-02-08 14:58 ` Marek Vasut 2016-02-12 15:53 ` Simon Glass 2016-02-12 16:04 ` Hannes Schmelzer 2016-02-18 10:05 ` Schrempf Frieder 2016-02-18 15:32 ` Marek Vasut 2016-02-18 17:14 ` Fabio Estevam 2016-02-22 7:03 ` Schrempf Frieder 2016-02-22 17:51 ` Maxime Jayat 2016-02-22 17:59 ` Fabio Estevam 2016-02-23 6:38 ` Hannes Schmelzer 2016-02-24 17:43 ` Marek Vasut 2016-02-25 4:13 ` Simon Glass 2016-02-25 17:56 ` Marek Vasut 2016-02-26 1:56 ` Simon Glass 2016-04-14 13:20 ` Diego 2016-04-15 10:53 ` Marek Vasut 2016-04-15 12:13 ` Diego 2016-04-18 23:54 ` Marek Vasut 2016-04-25 8:16 ` Stefan Roese 2016-04-27 2:14 ` Marek Vasut 2016-04-27 9:04 ` Diego 2016-04-27 16:13 ` Marek Vasut 2016-04-28 13:04 ` Diego 2016-04-28 22:49 ` Marek Vasut 2016-04-29 7:58 ` Diego 2016-05-03 21:01 ` Marek Vasut 2016-05-04 9:13 ` Diego 2016-05-04 11:45 ` Marek Vasut 2016-05-04 14:06 ` Diego 2016-05-04 21:36 ` Marek Vasut 2016-05-10 12:04 ` Diego 2016-05-10 12:32 ` Marek Vasut 2016-05-20 5:07 ` Rajesh Bhagat 2016-05-20 11:52 ` Marek Vasut 2016-02-04 8:06 ` Schrempf Frieder 2016-10-14 9:01 Michael Kasprowicz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.