Hi All,
Currently I am working with custom platform. It is based on imx6 sabresd. USB support is enabled in the u-boot. I am trying to copy uImage file using "fatload usb 0:1 0x12000000 uImage" to RAM at uboot. But sometime I am observing below errors,.... eventually copy fails.
....
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x82008d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x128d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x2008d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x128d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x2008d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x128d80
My analysis for above token ID's :
token=0x1f8c80
31 30:16 15 14:12 11:10 9:8 7:0
0 000000000011111 1 000 11 00 10000000
Bits analysis :
31 Data Toggle bit. ‘1b’ indicates initial data toggle comes from incoming qTD DT bit. Host controller replaces DT bit in the queue head from the DT bit in the qTD. OR ‘0b’ indicates Ignore DT bit from incoming qTD.
30:16 Total Bytes to transfer. If the value of this field is zero when the host controller fetches this transfer descriptor(and the Active bit-7th bit is set), the host controller executes a 0 length transaction and retries the transfer descriptor. This field is zero after the transaction completes. Note that for a 0 length transaction, it was 0 before the transaction was started. When this condition occurs the Active bit is set to 0.
15 Interrupt on Completion. Specifies that when this qTD is completed, the host controller should issue an Interrupt at the next interrupt threshold.
14:12 Current Page. An index into the qTD buffer ptr list. Host controller doesn’t write this field back when qTD is retried.
11:10 Error counter. This value has a maximum value (3) on successful completion of a transaction, on error decrements the counter.
9:8 PID Code. Indicates the type of token, 00b indicates an OUT Token(Informs the USB device that the host wishes to send information.) OR 01b indicates an IN Token(Informs the USB device that the host wishes to read information).
7:0 Status. Contains the status of the last transaction performed on this qTD. Bit 7 indicates the Active bit (Set 1 by S/W to enable the execution of transactions by the host controller). So here in all Token IDs indicates that data transfer is not complete, since active bit is always set.
So is there any software solution for the above issue seen at bootloader.
Thanks,
Jaya
Hi Jaya
issue may be related to weak usb signals caused by board layout and signal losses
in board material and connectors/cables. One can recheck board layout using
also may be useful AN4589 Configuring USB on i.MX 6 Series Processors
Best regards
igor
Thank you Igor for your reply.
The issue is not observed with Linux kernel. Different USB Mass storage devices works properly in Linux kernel. This is observed only in Bootloader(u-boot).
Is there any error mentioned above is indicating as HW issue?
Thanks and Regards,
Jaya
what uboot used in the case, one can try with nxp latest releases:
https://source.codeaurora.org/external/imx/uboot-imx/tree/?h=imx_v2020.04_5.4.70_2.3.0
Best regards
igor
Hello, @igorpadykov
I also encount this u-boot Error which access the files on USB drive.
I used the recently U-Boot 2020.04-5.4.70
Hi Jaya
to narrow down problem, if it is caused by hardware one can try to reproduce issue on
NXP Sabre SD board.
Best regards
igor
"U-Boot 2020.01" software is not official nxp software. Please try latest nxp official uboot releases
from source.codeaurora.org/external/imx repository
https://source.codeaurora.org/external/imx/uboot-imx/tree/?h=imx_v2020.04_5.4.70_2.3.0
Best regards
igor
Hi Igor,
Thanks for your kind support.
Using git cherry pick I have applied usb patches from u-boot 2020.04 and tested using few of the USBs(like Sandisk, Kingston). To test this recursively I made changes in
u-boot in such way it reboots after copy file from USB. Kept over night testing. Likewise tested many times. The USB intermittent issue seen still.
From debugs it was observed that, every time when issue was seen it was failed during first blocks transfer.
The error pattern is :
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x2008d80
EHCI timed out on TD - token=0xd8d80
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=0x1f8c80
EHCI timed out on TD - token=0x128d80
EHCI timed out on TD - token=0xd8d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
My analysis for above pattern :
31 | 30:16 | 15 | 14:12 | 11:10 | 9:8 | 7:0 |
0 | 000000000011111 | 1 | 000 | 11 | 00 | 10000000 |
7th bit is set : qTD has been initialized and is ready to use. Enables the execution of transactions by the host controller.
9:8 are 00 : OUT token (generates token 0xE1)
11:10 are 11 : The host controller decrements the count for each consecutive error and writes it back to the qTD if the transaction fails. Write this field as 0x3, to allow up to three retries for the transfer.
14–10 bits are set to 000
15 bit is 1 : bit is set, when this qTD is completed, the host controller should issue an interrupt at the next interrupt threshold. Actually here qTD is not completed, not sure why this bit is set
30:16 bits are 000000000011111 : the 31 bytes to be moved with this transfer descriptor transfer.
31 bit is 0 : It is cleared for SETUP packets.
31 | 30:16 | 15 | 14:12 | 11:10 | 9:8 | 7:0 |
0 | 000001000000000 | 1 | 000 | 11 | 01 | 10000000 |
7th bit is set : qTD has been initialized and is ready to use. Enables the execution of transactions by the host controller
9:8 are 01 : IN token (generates token 0x69)
11:10 are 11 : The host controller decrements the count for each consecutive error and writes it back to the qTD if the transaction fails. Write this field as 0x3, to allow up to three retries for the transfer.
14–10 bits are set to 000
15 bit is 1 : bit is set, when this qTD is completed, the host controller should issue an interrupt at the next interrupt threshold. Actually here qTD is not completed, not sure why this bit is set
30:16 bits are 000001000000000: the 512 bytes to be moved with this transfer descriptor transfer.
31 bit is 0 : It is cleared for SETUP packets.
31 | 30:16 | 15 | 14:12 | 11:10 | 9:8 | 7:0 |
0 | 000000000001101 | 1 | 000 | 11 | 01 | 10000000 |
7th bit is set : qTD has been initialized and is ready to use. Enables the execution of transactions by the host controller
9:8 are 01 : IN token (generates token 0x69)
11:10 are 11 : The host controller decrements the count for each consecutive error and writes it back to the qTD if the transaction fails. Write this field as 0x3, to allow up to three retries for the transfer.
14–10 bits are set to 000
15 bit is 1 : bit is set, when this qTD is completed, the host controller should issue an interrupt at the next interrupt threshold. Actually here qTD is not completed, not sure why this bit is set
30:16 bits are 000000000001101: the 13 bytes to be moved with this transfer descriptor transfer.
31 bit is 0 : It is cleared for SETUP packets.
31 | 30:16 | 15 | 14:12 | 11:10 | 9:8 | 7:0 |
1 | 000000000000000 | 1 | 000 | 11 | 01 | 10000000 |
7th bit is set : qTD has been initialized and is ready to use. Enables the execution of transactions by the host controller
9:8 are 01 : IN token (generates token 0x69)
11:10 are 11 : The host controller decrements the count for each consecutive error and writes it back to the qTD if the transaction fails. Write this field as 0x3, to allow up to three retries for the transfer.
14–10 bits are set to 000
15 bit is 1 : bit is set, when this qTD is completed, the host controller should issue an interrupt at the next interrupt threshold. Actually here qTD is not completed, not sure why this bit is set
30:16 bits are 000000000000000: If the value of this field is zero when the host controller fetches this transfer descriptor (and the active bit is set), the host controller executes a zero-length transaction and retires the transfer descriptor.
31 bit is 1: . This bit is set for IN and OUT transactions.
31 | 30:16 | 15 | 14:12 | 11:10 | 9:8 | 7:0 |
0 | 000000000010010 | 1 | 000 | 11 | 01 | 10000000 |
7th bit is set : qTD has been initialized and is ready to use. Enables the execution of transactions by the host controller
9:8 are 01 : IN token (generates token 0x69)
11:10 are 11 : The host controller decrements the count for each consecutive error and writes it back to the qTD if the transaction fails. Write this field as 0x3, to allow up to three retries for the transfer.
14–10 bits are set to 000
15 bit is 1 : bit is set, when this qTD is completed, the host controller should issue an interrupt at the next interrupt threshold. Actually here qTD is not completed, not sure why this bit is set
30:16 bits are 000000000010010 : the 18 bytes to be moved with this transfer descriptor transfer
31 bit is 0 : It is cleared for SETUP packets.
The above shown pattern all token ID's Active bit(7th bit) is set, means qTD had been initialized and was ready to use but transaction was failed. So it went for retries, it repeated 3 times(see 11:10 bits are 11). Not clear about root cause of the issue to fix.
Thank you,
Jaya
Hi Jaya
to narrow down problem, if it is caused by hardware one can try to reproduce issue on
NXP Sabre SD board.
Best regards
igor