[U-Boot] U-Boot Rockchip dwc_hcd question for low-speed devices
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip) board, and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because they work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though USB_PORT_STAT_CONNECTION goes high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work in any hub port, including any of the ports directly on the board. All attempts to read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device *dev, uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak, and hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat = HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I wonder whether this code is actually expected to support full-speed and low-speed devices. Do you have any thoughts on the matter? I wish I were more of a USB expert, but I'm regrettably quite a novice.
Regards,
Josh
+Marek, Stephen
Hi Josh,
On 18 December 2015 at 06:26, Josh Sanford joshs6502@gmail.com wrote:
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip) board, and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because they work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though USB_PORT_STAT_CONNECTION goes high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work in any hub port, including any of the ports directly on the board. All attempts to read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device *dev, uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak, and hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat = HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I wonder whether this code is actually expected to support full-speed and low-speed devices. Do you have any thoughts on the matter? I wish I were more of a USB expert, but I'm regrettably quite a novice.
I believe the split transaction issue is currently being resolved for DWC. See for example Stefan Bruns' series from 13th December. It might be worth trying that out.
Regards, Simon
Thanks Simon. I'm having difficulty finding anything by Stefan Bruns around that time frame, or much of anything recent pertaining to DWC. (I only checked the u-boot-denx.git and u-boot-rockchip.git branches.) Am I looking in the wrong place?
On Sat, Dec 19, 2015 at 3:30 PM, Simon Glass sjg@chromium.org wrote:
+Marek, Stephen
Hi Josh,
On 18 December 2015 at 06:26, Josh Sanford joshs6502@gmail.com wrote:
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip)
board,
and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because they work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though USB_PORT_STAT_CONNECTION
goes
high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work in
any
hub port, including any of the ports directly on the board. All
attempts to
read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device
*dev,
uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak, and hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat = HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I
wonder
whether this code is actually expected to support full-speed and
low-speed
devices. Do you have any thoughts on the matter? I wish I were more of
a
USB expert, but I'm regrettably quite a novice.
I believe the split transaction issue is currently being resolved for DWC. See for example Stefan Bruns' series from 13th December. It might be worth trying that out.
Regards, Simon
Hi Josh,
On 21 December 2015 at 07:11, Josh Sanford joshs6502@gmail.com wrote:
Thanks Simon. I'm having difficulty finding anything by Stefan Bruns around that time frame, or much of anything recent pertaining to DWC. (I only checked the u-boot-denx.git and u-boot-rockchip.git branches.) Am I looking in the wrong place?
This is just patches at present - see here:
http://patchwork.ozlabs.org/project/uboot/list/?submitter=67055&state=*
Regards, Simon
On Sat, Dec 19, 2015 at 3:30 PM, Simon Glass sjg@chromium.org wrote:
+Marek, Stephen
Hi Josh,
On 18 December 2015 at 06:26, Josh Sanford joshs6502@gmail.com wrote:
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip) board, and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because they work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though USB_PORT_STAT_CONNECTION goes high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work in any hub port, including any of the ports directly on the board. All attempts to read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device *dev, uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak, and hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat = HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I wonder whether this code is actually expected to support full-speed and low-speed devices. Do you have any thoughts on the matter? I wish I were more of a USB expert, but I'm regrettably quite a novice.
I believe the split transaction issue is currently being resolved for DWC. See for example Stefan Bruns' series from 13th December. It might be worth trying that out.
Regards, Simon
Thanks Simon,
I've been looking through the code you referenced. So these patches are just standalone snippets and not yet part of any branch? (I'm just not familiar with U-Boot's development process.)
Josh
On Tue, Jan 5, 2016 at 7:25 PM, Simon Glass sjg@chromium.org wrote:
Hi Josh,
On 21 December 2015 at 07:11, Josh Sanford joshs6502@gmail.com wrote:
Thanks Simon. I'm having difficulty finding anything by Stefan Bruns
around
that time frame, or much of anything recent pertaining to DWC. (I only checked the u-boot-denx.git and u-boot-rockchip.git branches.) Am I
looking
in the wrong place?
This is just patches at present - see here:
http://patchwork.ozlabs.org/project/uboot/list/?submitter=67055&state=*
Regards, Simon
On Sat, Dec 19, 2015 at 3:30 PM, Simon Glass sjg@chromium.org wrote:
+Marek, Stephen
Hi Josh,
On 18 December 2015 at 06:26, Josh Sanford joshs6502@gmail.com wrote:
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip) board, and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because
they
work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though
USB_PORT_STAT_CONNECTION
goes high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work
in
any hub port, including any of the ports directly on the board. All attempts to read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device *dev, uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak,
and
hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat
=
HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I wonder whether this code is actually expected to support full-speed and low-speed devices. Do you have any thoughts on the matter? I wish I were more
of
a USB expert, but I'm regrettably quite a novice.
I believe the split transaction issue is currently being resolved for DWC. See for example Stefan Bruns' series from 13th December. It might be worth trying that out.
Regards, Simon
Hi Josh,
On 8 January 2016 at 06:27, Josh Sanford joshs6502@gmail.com wrote:
Thanks Simon,
I've been looking through the code you referenced. So these patches are just standalone snippets and not yet part of any branch? (I'm just not familiar with U-Boot's development process.)
Please put your reply at the bottom or the threads will get very confusing!
There is some information here that might help:
http://www.denx.de/wiki/U-Boot/Patches
In short, yes these are patches, and will be applied at some point, at which point they become part of 'mainline' and end up in the next release. If you test them you can reply with your Tested-by tag which helps the process.
Regards, Simon
Josh
On Tue, Jan 5, 2016 at 7:25 PM, Simon Glass sjg@chromium.org wrote:
Hi Josh,
On 21 December 2015 at 07:11, Josh Sanford joshs6502@gmail.com wrote:
Thanks Simon. I'm having difficulty finding anything by Stefan Bruns around that time frame, or much of anything recent pertaining to DWC. (I only checked the u-boot-denx.git and u-boot-rockchip.git branches.) Am I looking in the wrong place?
This is just patches at present - see here:
http://patchwork.ozlabs.org/project/uboot/list/?submitter=67055&state=*
Regards, Simon
On Sat, Dec 19, 2015 at 3:30 PM, Simon Glass sjg@chromium.org wrote:
+Marek, Stephen
Hi Josh,
On 18 December 2015 at 06:26, Josh Sanford joshs6502@gmail.com wrote:
All,
I am trying to use USB within U-Boot on a Firefly RK3288 (Rockchip) board, and I am able to enumerate high-speed devices, but not full-speed or low-speed devices. I know that the devices are functional, because they work on the same physical hardware when I boot into Linux. Note that I'm using "U-Boot 2014.10-RK3288-02".
As an aside, the built-in "USB 2.0 Hub [MTT]" hub never generates a USB_PORT_STAT_C_CONNECTION for me, even though USB_PORT_STAT_CONNECTION goes high immediately after powering on, so I forcibly assert USB_PORT_STAT_C_CONNECTION to allow the rest of the tree to enumerate.
High-speed devices can be nested as deeply as I wish and still show up properly, but I can't get low-speed devices (i.e. a keyboard) to work in any hub port, including any of the ports directly on the board. All attempts to read from my low-speed devices return all zeros. When I dig a little deeper, I find myself in int dwc_wait_for_complete(struct usb_device *dev, uint32_t channel_num, uint32_t *hcStat, uint32_t *errCnt) {}.
On the second iteration through the goto loop, hcintn.b.chhltd and hcintn.b.xacterr are both asserted, but hcintn.b.ack, hcintn.b.nak, and hcintn.b.nyet are not, and errCnt is only 1, so the code sets *hcStat = HCSTAT_REINIT and returns.
I do notice that dwc_hcd.c seems not to have any code to support split transactions (or perhaps I simply haven't seen it yet). If true, I wonder whether this code is actually expected to support full-speed and low-speed devices. Do you have any thoughts on the matter? I wish I were more of a USB expert, but I'm regrettably quite a novice.
I believe the split transaction issue is currently being resolved for DWC. See for example Stefan Bruns' series from 13th December. It might be worth trying that out.
Regards, Simon
On Montag, 11. Januar 2016 09:59:09 CET Simon Glass wrote:
Hi Josh,
On 8 January 2016 at 06:27, Josh Sanford joshs6502@gmail.com wrote:
Thanks Simon,
I've been looking through the code you referenced. So these patches are just standalone snippets and not yet part of any branch? (I'm just not familiar with U-Boot's development process.)
Please put your reply at the bottom or the threads will get very confusing!
There is some information here that might help:
http://www.denx.de/wiki/U-Boot/Patches
In short, yes these are patches, and will be applied at some point, at which point they become part of 'mainline' and end up in the next release. If you test them you can reply with your Tested-by tag which helps the process.
Just a small followup, I have reworked the patches. I have followed Simons? suggestion and split the "core" transfer from the chunk_msg loop into a seperate function. The SPLIT changes are now much more self contained.
The patches need some cleanup, especially the INTERRUPT transfer support (yay, that did not work before), so I will post it soon, but maybe not earlier than during the weekend.
Kind regards,
Stefan
participants (3)
-
Josh Sanford -
Simon Glass -
Stefan Bruens