[Solved] EHCI timed out on TD - token=XXXX
Posted by rayvt
|
[Solved] EHCI timed out on TD - token=XXXX July 05, 2017 04:45PM |
Registered: 11 years ago Posts: 18 |
Many people have run into the problem on a Pogoplug with a USB disk that refuses to boot. If you can see the U-Boot console, either with a serial cable or netconsole, the error message is "EHCI timed out on TD - token=0x{something}" repeated over and over again. A related problem is a drive which randomly fails to be detected by uboot, but without any error message.
Frustratingly, once the Pogoplug is running Linux, the same disk works perfectly ok, it is only U-boot that has problems with it. Ugh
I have found the problem and fixed it.
It has sometimes been suggested that two environment variables, "usb_pgood_delay" and "usb_ready_retry" be set. These can be removed. They had nothing to do with the problem and did nothing to fix or resolve it.
Pending the time until the fix gets pulled in to the "official" U-Boot code, I have created u-boot firmware and made it available for download.
This is a fixed version of the bodhi "U-Boot 2016.05 (May 20 2017 - 12:42:17 -0500)"
filename: "uboot.2016.05-tld-1.pogo_e02.mtd0.kwb"
The versions I created are for Pogoplug_E02 (pink pogoplug) and Pogoplug_V4. I can build versions for other pogoplugs, just ask.
Link to the folder containing the files:
https://www.dropbox.com/sh/nwjwxzdy0ifd1aq/AADcduZlnF9psWjRBpMB-cMja?dl=0
Link to the patch file. (It is also in the above folder.)
https://www.dropbox.com/s/nrkrd1no63viuu8/uboot-bodhi-2016.05-timeoutTD.patch?dl=0
For your convenience, there is also a script to install the firmware.
Usage: install-new-uboot.sh {filename.kwb}
Frustratingly, once the Pogoplug is running Linux, the same disk works perfectly ok, it is only U-boot that has problems with it. Ugh
I have found the problem and fixed it.
It has sometimes been suggested that two environment variables, "usb_pgood_delay" and "usb_ready_retry" be set. These can be removed. They had nothing to do with the problem and did nothing to fix or resolve it.
Pending the time until the fix gets pulled in to the "official" U-Boot code, I have created u-boot firmware and made it available for download.
This is a fixed version of the bodhi "U-Boot 2016.05 (May 20 2017 - 12:42:17 -0500)"
filename: "uboot.2016.05-tld-1.pogo_e02.mtd0.kwb"
The versions I created are for Pogoplug_E02 (pink pogoplug) and Pogoplug_V4. I can build versions for other pogoplugs, just ask.
Link to the folder containing the files:
https://www.dropbox.com/sh/nwjwxzdy0ifd1aq/AADcduZlnF9psWjRBpMB-cMja?dl=0
Link to the patch file. (It is also in the above folder.)
https://www.dropbox.com/s/nrkrd1no63viuu8/uboot-bodhi-2016.05-timeoutTD.patch?dl=0
For your convenience, there is also a script to install the firmware.
Usage: install-new-uboot.sh {filename.kwb}
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 05, 2017 04:47PM |
Registered: 11 years ago Posts: 18 |
[next post]
For those who are curious about the error message:
EHCI timed out on TD - token=0x80008d88
and
EHCI timed out on TD - token=0x8d88
TD stands for "Queue Element Transfer Descriptor (qTD)", which is a micro-code instruction for the EHCI USB chip. A TD controls the I/O transfer of up to 20480 bytes of data. One I/O operation consists of one or more TDs. (Ref: Enhanced Host Controller Interface Specification for Universal Serial Bus Ch. 3.5)
The "token" field is detailed information, control, and status of the TD's data transfer. In particular, the rightmost byte is the status field. 0x80 bit means the TD is active and the data transfer has not yet completed. 0x08 bit means there was some sort of data transfer error (XactErr).
U-boot allows 5 seconds for the last TD to complete, before it declares a time-out error. The largest possible I/O operation in U-boot is 65535 blocks or about 33 MB. Depending on the disk, this takes about 0.9s to 1.8s.
For those who are curious about the error message:
EHCI timed out on TD - token=0x80008d88
and
EHCI timed out on TD - token=0x8d88
TD stands for "Queue Element Transfer Descriptor (qTD)", which is a micro-code instruction for the EHCI USB chip. A TD controls the I/O transfer of up to 20480 bytes of data. One I/O operation consists of one or more TDs. (Ref: Enhanced Host Controller Interface Specification for Universal Serial Bus Ch. 3.5)
The "token" field is detailed information, control, and status of the TD's data transfer. In particular, the rightmost byte is the status field. 0x80 bit means the TD is active and the data transfer has not yet completed. 0x08 bit means there was some sort of data transfer error (XactErr).
U-boot allows 5 seconds for the last TD to complete, before it declares a time-out error. The largest possible I/O operation in U-boot is 65535 blocks or about 33 MB. Depending on the disk, this takes about 0.9s to 1.8s.
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 05, 2017 04:52PM |
Registered: 11 years ago Posts: 18 |
[next post]
Analysis of the U-Boot bug. And the fix.
There were two problems that caused this bug, which is what made it so difficult to reproduce and fix. The first problem laid a land-mine for the next I/O operation -- the innocent bystander -- to step on and blow up (timed out).
Most USB disks worked okay. The disks that had trouble generally worked okay on the 2012-era versions of U-boot, but would not work reliably on the 2016-era versions. Linux is okay with these drives because it has a quirks table which identifies USB chips that require special handling. It seems that USB drives with Genesys Logic chips are a major culprit.
The root problem is the USB chip in these drives have sporadic trouble when doing large I/O read transfers. The larger the number of blocks in the I/O read, the more probable that it will have a transfer error. This is why the older versions of U-boot worked. The older versions have a maximum block count of 20, whereas the new versions have 65535.
If the drive gets a transfer error, it refuses to do any other I/O transfer until the error is properly cleared and reset. U-boot did not do this, so every subsequent disk read would get a timeout error because the drive would not send any data. The next two I/O operations are to read the status and reset the drive -- both of which got a timeout. The only way to clear it was to do a U-boot USB RESET command.
The fix has two parts. The first part is to properly clear and reset the USB disk when it gets a transfer error. This gets rid of the timeout errors.
The second part is to dynamically reduce the maximum block count at every read I/O that throws a transfer error. We don't want to permanently lower the max block count, because even with a 33MB blocksize fewer than 20% of the reads get an error. Over 80% are successful. And reducing the block count greatly slows down the read operation, so we don't want to do that. For a 25MB read, a successful read with the default max block count (65535) takes about 1.0 seconds but with a block count of 64 it takes 22 seconds. With the dynamic adjustment, the troublesome drives took average 1.2 seconds. Much better than 22 seconds.
Every read operation starts at the maximum block size. The dynamic reduction begins anew with each read.
There is new environment variable so that the maximum block count is a parameter instead of hard-coded. This variable is "usb_max_blk". The default is still 65535. However, with the dynamic reduction I never had a need to set this variable -- test runs with thousands of reads were all successful.
A related problem is that some drives are slow to come up. Linux handles this by issuing a spinup command and allowing more time for the drive to respond. The fix was to do the same (in two places in the U-boot code).
Patch files are in my dropbox folder:
https://www.dropbox.com/sh/nwjwxzdy0ifd1aq/AADcduZlnF9psWjRBpMB-cMja?dl=0
one is for the bodhi "u-boot-kirkwood-2016.05-kirkwood-tld-2"
The other is for the "v2017.05" U-boot from denx.de's github.
Also there is an excel file containing the results & statistics of my
testing one such troublesome drive on a Pogoplug E02 (pink pogoplug).
--------
To execute a test run of 256 large reads, do these u-boot commands:
setenv rd 'mw.b 0xf0000 52 c00000 ; usb read 0x80000 0 c000 && crc32 0x80000 c00000 '
setenv cnt 100 ; while itest $cnt > 0 ; do echo '######' loop $cnt ; if run rd ; then ; else echo '!!!!!!!' fail at cnt $cnt; setenv cnt -1;fi ; setexpr cnt $cnt - 1; done
Analysis of the U-Boot bug. And the fix.
There were two problems that caused this bug, which is what made it so difficult to reproduce and fix. The first problem laid a land-mine for the next I/O operation -- the innocent bystander -- to step on and blow up (timed out).
Most USB disks worked okay. The disks that had trouble generally worked okay on the 2012-era versions of U-boot, but would not work reliably on the 2016-era versions. Linux is okay with these drives because it has a quirks table which identifies USB chips that require special handling. It seems that USB drives with Genesys Logic chips are a major culprit.
The root problem is the USB chip in these drives have sporadic trouble when doing large I/O read transfers. The larger the number of blocks in the I/O read, the more probable that it will have a transfer error. This is why the older versions of U-boot worked. The older versions have a maximum block count of 20, whereas the new versions have 65535.
If the drive gets a transfer error, it refuses to do any other I/O transfer until the error is properly cleared and reset. U-boot did not do this, so every subsequent disk read would get a timeout error because the drive would not send any data. The next two I/O operations are to read the status and reset the drive -- both of which got a timeout. The only way to clear it was to do a U-boot USB RESET command.
The fix has two parts. The first part is to properly clear and reset the USB disk when it gets a transfer error. This gets rid of the timeout errors.
The second part is to dynamically reduce the maximum block count at every read I/O that throws a transfer error. We don't want to permanently lower the max block count, because even with a 33MB blocksize fewer than 20% of the reads get an error. Over 80% are successful. And reducing the block count greatly slows down the read operation, so we don't want to do that. For a 25MB read, a successful read with the default max block count (65535) takes about 1.0 seconds but with a block count of 64 it takes 22 seconds. With the dynamic adjustment, the troublesome drives took average 1.2 seconds. Much better than 22 seconds.
Every read operation starts at the maximum block size. The dynamic reduction begins anew with each read.
There is new environment variable so that the maximum block count is a parameter instead of hard-coded. This variable is "usb_max_blk". The default is still 65535. However, with the dynamic reduction I never had a need to set this variable -- test runs with thousands of reads were all successful.
A related problem is that some drives are slow to come up. Linux handles this by issuing a spinup command and allowing more time for the drive to respond. The fix was to do the same (in two places in the U-boot code).
Patch files are in my dropbox folder:
https://www.dropbox.com/sh/nwjwxzdy0ifd1aq/AADcduZlnF9psWjRBpMB-cMja?dl=0
one is for the bodhi "u-boot-kirkwood-2016.05-kirkwood-tld-2"
The other is for the "v2017.05" U-boot from denx.de's github.
Also there is an excel file containing the results & statistics of my
testing one such troublesome drive on a Pogoplug E02 (pink pogoplug).
--------
To execute a test run of 256 large reads, do these u-boot commands:
setenv rd 'mw.b 0xf0000 52 c00000 ; usb read 0x80000 0 c000 && crc32 0x80000 c00000 '
setenv cnt 100 ; while itest $cnt > 0 ; do echo '######' loop $cnt ; if run rd ; then ; else echo '!!!!!!!' fail at cnt $cnt; setenv cnt -1;fi ; setexpr cnt $cnt - 1; done
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 05, 2017 08:01PM |
Registered: 7 years ago Posts: 310 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 06, 2017 05:14PM |
Admin Registered: 13 years ago Posts: 18,591 |
@ray,
For USB HDDs such as WD brand, 10 seconds might not be enough to spin up.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
static int usb_test_unit_ready(ccb *srb, struct us_data *ss)
{
int retries = 10;
+ int gave_extra_time = 0;
do {
memset(&srb->cmd[0], 0, 12);
@@ -1019,6 +1052,13 @@
if ((srb->sense_buf[2] == 0x02) &&
(srb->sense_buf[12] == 0x3a))
return -1;
+ /* If the status is "Not Ready - becoming ready", give it
+ * more time. Linux issues a spinup command (once) and gives
+ * it 100 seconds. */
+ if (srb->sense_buf[2] == 0x02 && srb->sense_buf[12] == 0x04 &&
+ gave_extra_time == 0)
+ gave_extra_time = retries = 100; /* Allow 10 seconds. */
+
mdelay(100);
} while (retries--);
For USB HDDs such as WD brand, 10 seconds might not be enough to spin up.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 06, 2017 08:47PM |
Registered: 11 years ago Posts: 18 |
> For USB HDDs such as WD brand, 10 seconds might not be enough to spin up.
Could be. It was enough for the one WD drive I had. I thought that Linux's 100 seconds might be excessive -- BWDIK? It would be hard to argue that uboot shouldn't also do 100 seconds. It's not like we'd be waiting 100 seconds for a bad or missing drive -- the drive is responding.
So change it to:
gave_extra_time = retries = 1000; /* Allow 100 seconds. */
Could be. It was enough for the one WD drive I had. I thought that Linux's 100 seconds might be excessive -- BWDIK? It would be hard to argue that uboot shouldn't also do 100 seconds. It's not like we'd be waiting 100 seconds for a bad or missing drive -- the drive is responding.
So change it to:
gave_extra_time = retries = 1000; /* Allow 100 seconds. */
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 06, 2017 08:53PM |
Admin Registered: 13 years ago Posts: 18,591 |
ray,
> gave_extra_time = retries = 1000; /* Allow 100 sec
> onds. */
It's probably OK for mainline. Adding a u-boot env is hard to get accepted in mainline. But the max block env is a good one, so I think they will be OK with it.
For my build, I would keep the usb_ready_retry env for total spin up time.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/07/2017 02:09AM by bodhi.
> gave_extra_time = retries = 1000; /* Allow 100 sec
> onds. */
It's probably OK for mainline. Adding a u-boot env is hard to get accepted in mainline. But the max block env is a good one, so I think they will be OK with it.
For my build, I would keep the usb_ready_retry env for total spin up time.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/07/2017 02:09AM by bodhi.
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 07, 2017 02:18AM |
Admin Registered: 13 years ago Posts: 18,591 |
Hi ray,
Consider the scenarios:
1. For boxes that boot with a HDD or MMC rootfs, we don't care much about the spin up time of the USB drive. Actually we want to ignore the failure rather quickly.
2. For boxes that boot with USB rootfs, we want u-boot to wait for a long period until the drive spun up.
I understood you would take the approach that is acceptable to upstream. But I think there has been a shortage of configurable parameters to do what we want for certain use cases.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Consider the scenarios:
1. For boxes that boot with a HDD or MMC rootfs, we don't care much about the spin up time of the USB drive. Actually we want to ignore the failure rather quickly.
2. For boxes that boot with USB rootfs, we want u-boot to wait for a long period until the drive spun up.
I understood you would take the approach that is acceptable to upstream. But I think there has been a shortage of configurable parameters to do what we want for certain use cases.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 07, 2017 04:39PM |
Admin Registered: 13 years ago Posts: 18,591 |
ray,
Excellent works :) I've tested your patch on my GoFlex Home, with a 2TB WD Element USB HDD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Excellent works :) I've tested your patch on my GoFlex Home, with a 2TB WD Element USB HDD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 07, 2017 05:21PM |
Registered: 11 years ago Posts: 18 |
Quote
For boxes that boot with a HDD or MMC rootfs, we don't care much about the spin up time of the USB drive. Actually we want to ignore the failure rather quickly.
That's the maximum time we will allow the drive to keep saying "Not Ready". As soon as the drive says "Ready" we are good to go. If the drive doesn't respond at all, we don't retry, we fail immediately.
I only have a pogoplug, so I could not test real HDD or MMC. I have 3 WD USB drives, two became ready immediately and one took about 3 seconds to say "ready". Before that, it kept returning "Not Ready - becoming ready". I happen to know it was doing a spinup because I could feel it with my hand.
The original uboot code only waited 1 second (10 tries at 100 msec each). Not that if the drive returns anything exept "Not Ready", we do not give any extra retries.
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 07, 2017 06:42PM |
Admin Registered: 13 years ago Posts: 18,591 |
>
> That's the maximum time we will allow the d
> rive to keep saying "Not Ready". As soon as the d
> rive says "Ready" we are good to go. If the drive
> doesn't respond at all, we don't retry, we fail im
> mediately.
I knew. The max spin time is just that. So it could be successful, like in 1/2 second, and we are done.
> The original uboot code only waited 1 second (10 t
> ries at 100 msec each). Not that if the drive ret
> urns anything exept "Not Ready", we do not give an
> y extra retries.
True. It's always been like this in mainline code.
So I basically don't disagree with what you said. But to have the most flexible implementation, the max spin time should be adjustable by user. Linux have quirks table, but u-boot does not. Therefore I'll merge your patch, but keeping the code about factoring usb_ready_retry env into the max spin time. In a multi-drive configuration, this env will be useful.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> That's the maximum time we will allow the d
> rive to keep saying "Not Ready". As soon as the d
> rive says "Ready" we are good to go. If the drive
> doesn't respond at all, we don't retry, we fail im
> mediately.
I knew. The max spin time is just that. So it could be successful, like in 1/2 second, and we are done.
> The original uboot code only waited 1 second (10 t
> ries at 100 msec each). Not that if the drive ret
> urns anything exept "Not Ready", we do not give an
> y extra retries.
True. It's always been like this in mainline code.
So I basically don't disagree with what you said. But to have the most flexible implementation, the max spin time should be adjustable by user. Linux have quirks table, but u-boot does not. Therefore I'll merge your patch, but keeping the code about factoring usb_ready_retry env into the max spin time. In a multi-drive configuration, this env will be useful.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 07, 2017 07:51PM |
Registered: 11 years ago Posts: 18 |
Quote
But to have the most flexible implementation, the max spin time should be adjustable by user. Linux have quirks table, but u-boot does not. Therefore I'll merge your patch, but keeping the code about factoring usb_ready_retry env into the max spin time. In a multi-drive configuration, this env will be useful.
Sounds good.
Yeah, the quirks thing...Linux has a lot of flexibility because it is continually updated, and it can to clever retries, etc.. And it's got logging, a console, etc. Uboot code is basically static, and you don't want to put a lot of special purpose code in it -- like a quirks table. And for most people, no logging and no console, so if it doesn't work all you know is that the dang thing won't boot.
So from that aspect, it's better to lean toward robustness and reliability. Better to sometimes take 10-15 seconds to boot -- and boot everything, than to take 5 seconds to boot most disks but utterly fail on many disks -- or worse yet, fail 50% of the time and succeed 50% of the time.
Anyway, uboot code is just to get Linux booted up, so speed is not as important as robustness.
I don't disagree about leaving usb_ready_retry env in, even though with the patched code it doesn't seem to be needed. Most people will not be aware that there is even such an environment variable. And when people try googling their problem they get a huge number of hits, mostly other people having the same problem. But also a lot of suggestions like "try this, try that". Nobody really knew what the problem was, it was a lot of guessing and hoping. Even my worse drive worked 80% of the time, so holding your mouth funny and replugging it would generally work. And, of course, all the things that people tried didn't actually do any good, it just randomly worked or failed.
It took me quite a bit of work to isolate the problem, and it was really tricky to find & fix it. I bet I flashed 100-150 builds. Clearly nobody had tracked it down before me, otherwise it would have been fixed.
Better if the uboot code just works without having to configure special things.
----------
And now I just got exposed to the long-time programmer rule: Do not make any changes right before a vacation or holiday. 'cause I just tried to do a new build and it wouldn't build, something about "__bswaps12 not found". No time to track it down. I guess something updated and screwed up the cross-compile tools. ;-(
|
Re: [Solved] EHCI timed out on TD - token=XXXX July 08, 2017 04:46AM |
Admin Registered: 13 years ago Posts: 18,591 |
Quote
It took me quite a bit of work to isolate the problem, and it was really tricky to find & fix it. I bet I flashed 100-150 builds. Clearly nobody had tracked it down before me, otherwise it would have been fixed.
:)) you should be booting with kwboot, before final testing with u-boot flashed in NAND.
In any case, mucho kudos for perserverance and technical expertise in fixing this problem :) Nobody wanted to get to the bottom of this, they just used a different flash drive,
Quote
Better if the uboot code just works without having to configure special things.
Only in the last 3-4 years or so, people have started getting serious about making u-boot robust enough. I think it has a lot to do with there have been developers who are actually getting paid in their day job to roll new u-boot in mainline.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/08/2017 04:47AM by bodhi.
|
IvanD
Re: [Solved] EHCI timed out on TD - token=XXXX February 19, 2018 08:03AM |
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 07, 2018 01:40AM |
Registered: 5 years ago Posts: 17 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 07, 2018 03:05AM |
Admin Registered: 13 years ago Posts: 18,591 |
t96,
> I have the same problem
> As I could see, this patch was not applied to
> mainline.
>
> Is there any other way to make it work or I need
> to make custom u-boot with this fix?
Depending on which box you want to install. This patch was included in the Kirkwood u-boots I've released in this thread:
https://forum.doozan.com/read.php?3,12381
For other boxes such as DNS-325, then yes it would need to be in a new u-boot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I have the same problem
> As I could see, this patch was not applied to
> mainline.
>
> Is there any other way to make it work or I need
> to make custom u-boot with this fix?
Depending on which box you want to install. This patch was included in the Kirkwood u-boots I've released in this thread:
https://forum.doozan.com/read.php?3,12381
For other boxes such as DNS-325, then yes it would need to be in a new u-boot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 07, 2018 04:16AM |
Registered: 5 years ago Posts: 17 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 07, 2018 04:30AM |
Admin Registered: 13 years ago Posts: 18,591 |
t96,
> I'm already in new u-boot
> I'm using 2018.07 which I compiled by myself,
> because DNS-325 is not in your release list.
Good! then apply that patch and rebuild.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I'm already in new u-boot
> I'm using 2018.07 which I compiled by myself,
> because DNS-325 is not in your release list.
Good! then apply that patch and rebuild.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 07, 2018 04:34AM |
Registered: 5 years ago Posts: 17 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 30, 2018 09:30AM |
Registered: 5 years ago Posts: 8 |
> Depending on which box you want to install. This
> patch was included in the Kirkwood u-boots I've
> released in this thread: https://forum.doozan.com/read.php?3,12381
>
> For other boxes such as DNS-325, then yes it would
> need to be in a new u-boot.
Hi,
Bodhi, do you have any plan to release the new oxnas uboot with "EHCI timed out on TD" patch included?
Getting same errors on 2 Pogoplug Pro, booting is very unstable on these. Would be a lifesaver ... ;)
br'
Noah
> patch was included in the Kirkwood u-boots I've
> released in this thread: https://forum.doozan.com/read.php?3,12381
>
> For other boxes such as DNS-325, then yes it would
> need to be in a new u-boot.
Hi,
Bodhi, do you have any plan to release the new oxnas uboot with "EHCI timed out on TD" patch included?
Getting same errors on 2 Pogoplug Pro, booting is very unstable on these. Would be a lifesaver ... ;)
br'
Noah
|
Re: [Solved] EHCI timed out on TD - token=XXXX November 30, 2018 05:13PM |
Admin Registered: 13 years ago Posts: 18,591 |
Noah,
I did not. No Pogo Oxnas users has report this. However, since you’ve requested, I will do eventually but not sure when :)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I did not. No Pogo Oxnas users has report this. However, since you’ve requested, I will do eventually but not sure when :)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 08, 2018 12:07AM |
Admin Registered: 13 years ago Posts: 18,591 |
Noah,
I think this issue is important enough to keep this box useful, so I've started buidling uboot.2015.10-tld-3.
I have no time to rebase to latest u-boot mainline, but this u-boot is adequate for our purpose :)
Stay tuned.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I think this issue is important enough to keep this box useful, so I've started buidling uboot.2015.10-tld-3.
I have no time to rebase to latest u-boot mainline, but this u-boot is adequate for our purpose :)
Stay tuned.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 08, 2018 02:02PM |
Registered: 5 years ago Posts: 8 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 08, 2018 04:22PM |
Admin Registered: 13 years ago Posts: 18,591 |
Hi Noah,
Here is the new u-boot. I don't have a USB HDD that causes the "Timeout on TD" error, so eventhough everything else is working the same on my box, I can't test this particular issue. Please test this before I officially release it.
This new version is a drop-in replacement for uboot.2015.10-tld-1 and uboot.2015.10-tld-2. So you only need to flash uboot.2015.10-tld-3.ox820.mtd0.img
Check bad blocks
Dropbox
uboot.2015.10-tld-3.ox820.bodhi.tar
md5:
992f668bcdae378ddc6b589fb827c83e
sha256:
e1853a5436f726528bc7449c5193722e1f7fc5108c4f64b8db1864f87447d479
There are 4 files in this tarball.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Here is the new u-boot. I don't have a USB HDD that causes the "Timeout on TD" error, so eventhough everything else is working the same on my box, I can't test this particular issue. Please test this before I officially release it.
This new version is a drop-in replacement for uboot.2015.10-tld-1 and uboot.2015.10-tld-2. So you only need to flash uboot.2015.10-tld-3.ox820.mtd0.img
Check bad blocks
dmesg | grep i badAnd flash
flash_erase /dev/mtd0 0x40000 4 nandwrite -s 262144 /dev/mtd0 uboot.2015.10-tld-3.ox820.mtd0.img
Dropbox
uboot.2015.10-tld-3.ox820.bodhi.tar
md5:
992f668bcdae378ddc6b589fb827c83e
sha256:
e1853a5436f726528bc7449c5193722e1f7fc5108c4f64b8db1864f87447d479
There are 4 files in this tarball.
Quote
uboot.2015.10-tld-3.ox820.mtd0.img
uboot.spl.2013.10.ox820.850mhz.mtd0.img
uboot.2015.10-tld-3.ox820.environment
uboot.2015.10-tld-3.ox820.environment.img
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 15, 2018 06:30AM |
Registered: 5 years ago Posts: 8 |
Hi there.
Sry for the delay.
I have new uBoot installed on both pogos but the testing results is a bit unreliable right now.
1 pogo is booting with most sticks 100%, other pogo is still getting "EHCI timed out on TD - token..." error on most cases.
Trying to figure it out. Maybe one of my pogos is broken by now, usb or or mtd0 ...
Have lost 3 stick to during the tests and reformats too :D
Sry for the delay.
I have new uBoot installed on both pogos but the testing results is a bit unreliable right now.
1 pogo is booting with most sticks 100%, other pogo is still getting "EHCI timed out on TD - token..." error on most cases.
Trying to figure it out. Maybe one of my pogos is broken by now, usb or or mtd0 ...
Have lost 3 stick to during the tests and reformats too :D
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 15, 2018 06:39AM |
Registered: 5 years ago Posts: 8 |
U-Boot 2015.10-tld-3 (Dec 08 2018 - 03:07:20 -0800)
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 0
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80400988
unable to get device descriptor (error=-1) retry: 5
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 4
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 3
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 2
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 1
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 0
2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
U-Boot 2015.10-tld-3 (Dec 08 2018 - 03:07:20 -0800)
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 0
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80400988
unable to get device descriptor (error=-1) retry: 5
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 4
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 3
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 2
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 1
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 0
2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Reset IDE: SATA PHY not ready for device 0
ide_preinit failed
no USB devices available
Reset IDE: SATA PHY not ready for device 0
ide_preinit failed
no USB devices available
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 0
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80400988
unable to get device descriptor (error=-1) retry: 5
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 4
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 3
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 2
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 1
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 0
2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
U-Boot 2015.10-tld-3 (Dec 08 2018 - 03:07:20 -0800)
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 0
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80400988
unable to get device descriptor (error=-1) retry: 5
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 4
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 3
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 2
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 1
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80a88
unable to get device descriptor (error=-1) retry: 0
2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Reset IDE: SATA PHY not ready for device 0
ide_preinit failed
no USB devices available
Reset IDE: SATA PHY not ready for device 0
ide_preinit failed
no USB devices available
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 15, 2018 10:01AM |
Registered: 7 years ago Posts: 366 |
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 15, 2018 04:23PM |
Admin Registered: 13 years ago Posts: 18,591 |
noah,
> U-Boot 2015.10-tld-3 (Dec 08 2018 -
> 03:07:20 -0800)
> OXNAS OX820
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> GNU ld (GNU Binutils for Debian) 2.28
> Hit any key to stop autoboot: 0
> starting USB...
> USB0: USB EHCI 1.00
There is an env missing. At u-boot console,
I am looking for usb_ready_retry.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> U-Boot 2015.10-tld-3 (Dec 08 2018 -
> 03:07:20 -0800)
> OXNAS OX820
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> GNU ld (GNU Binutils for Debian) 2.28
> Hit any key to stop autoboot: 0
> starting USB...
> USB0: USB EHCI 1.00
There is an env missing. At u-boot console,
printenv
I am looking for usb_ready_retry.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 17, 2018 08:45PM |
Admin Registered: 13 years ago Posts: 18,591 |
I think I can do a test with an old unused HDD. Stay tuned.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: [Solved] EHCI timed out on TD - token=XXXX December 18, 2018 12:48PM |
Registered: 5 years ago Posts: 8 |
printenv shows:
U-Boot 2015.10-tld-3 (Dec 08 2018 - 03:07:20 -0800)
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 3
0
OX820>
OX820> printenv
printenv
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm 0x60500000 0x60e00000 0x62c00000; else bootm 0x60500000 0x60e00000; fi; else if run load_dtb; then bootm 0x60500000 - 0x62c00000; else bootm 0x60500000; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide
disks=0 1 2 3
dtb_file=/boot/dts/ox820-pogoplug-pro.dtb
ethact=dwmac.40400000
ethaddr=00:25:31:01:22:DD
if_netconsole=ping $serverip
ipaddr=192.168.10.21
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device 0x62c00000 $dtb_file
load_initrd=echo loading uInitrd ...; load $bootdev $device 0x60e00000 /boot/uInitrd
load_uimage=echo loading uImage ...; load $bootdev $device 0x60500000 /boot/uImage
mainlineLinux=yes
mtdids=nand0=41000000.nand
mtdparts=mtdparts=41000000.nand:14m(boot),-(data)
nc_ready=1
ncip=192.168.10.250
preboot=run preboot_nc
preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3 4 5; do; sleep 1; if run if_netconsole; then setenv nc_ready 1; fi; done; if test $nc_ready -eq 1; then run start_netconsole; fi
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start"; setenv scan_ide "ide reset"; setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 0x60500000 /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.10.250
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=nc
stdin=nc
stdout=nc
uenv_import=echo importing envs ...; env import -t 0x60510000 $filesize
uenv_init_devices=setenv init_usb "usb start"; setenv init_ide "ide reset"; setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 0x60500000 /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read; fi; else if $devtype part $disknum; then run uenv_read; fi; fi
usb_custom_params=zswap.enabled=1
usb_ready_retry=15
Environment size: 2766/131068 bytes
U-Boot 2015.10-tld-3 (Dec 08 2018 - 03:07:20 -0800)
OXNAS OX820
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU ld (GNU Binutils for Debian) 2.28
Hit any key to stop autoboot: 3
0
OX820>
OX820> printenv
printenv
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm 0x60500000 0x60e00000 0x62c00000; else bootm 0x60500000 0x60e00000; fi; else if run load_dtb; then bootm 0x60500000 - 0x62c00000; else bootm 0x60500000; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide
disks=0 1 2 3
dtb_file=/boot/dts/ox820-pogoplug-pro.dtb
ethact=dwmac.40400000
ethaddr=00:25:31:01:22:DD
if_netconsole=ping $serverip
ipaddr=192.168.10.21
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device 0x62c00000 $dtb_file
load_initrd=echo loading uInitrd ...; load $bootdev $device 0x60e00000 /boot/uInitrd
load_uimage=echo loading uImage ...; load $bootdev $device 0x60500000 /boot/uImage
mainlineLinux=yes
mtdids=nand0=41000000.nand
mtdparts=mtdparts=41000000.nand:14m(boot),-(data)
nc_ready=1
ncip=192.168.10.250
preboot=run preboot_nc
preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3 4 5; do; sleep 1; if run if_netconsole; then setenv nc_ready 1; fi; done; if test $nc_ready -eq 1; then run start_netconsole; fi
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start"; setenv scan_ide "ide reset"; setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 0x60500000 /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.10.250
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=nc
stdin=nc
stdout=nc
uenv_import=echo importing envs ...; env import -t 0x60510000 $filesize
uenv_init_devices=setenv init_usb "usb start"; setenv init_ide "ide reset"; setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 0x60500000 /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read; fi; else if $devtype part $disknum; then run uenv_read; fi; fi
usb_custom_params=zswap.enabled=1
usb_ready_retry=15
Environment size: 2766/131068 bytes
