Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
- Reply: Klaus_Küchemann : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Reply: Mark Millard : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Reply: Mark Millard : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- In reply to: bob prohaska : "Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 30 Sep 2022 16:40:10 UTC
> Am 30.09.2022 um 02:27 schrieb bob prohaska <fbsd@www.zefox.net>: > …… > . > I just captured an example now. Because of the file’s > size it's at > http://nemesis.zefox.com/~fbsd/ > in a file named …….. O.K., you now have extended logs..fine... comparing success/fail we see: -fail--- port 1 returns 0 pgood_delay=2000ms devnum=1 poweron: query_delay=2000 connect_timeout=3000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 311 Change 1 devnum=1 port=1: USB dev found usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 311, change 1, 1.5 Mb/s ... STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 Cannot enable port 1 after 5 retries, disabling port. Maybe the USB cable is bad? cannot reset port 1!? -success---- port 1 returns 0 pgood_delay=2000ms devnum=1 poweron: query_delay=2000 connect_timeout=3000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 511 Change 1 devnum=1 port=1: USB dev found usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 511, change 1, 480 Mb/s -- So we now know that when it fails, the issue consists of an underpowered port1 of the USB-Hub ( what doesn't necessarily mean that the hub itself is the root cause) We see the values of query_delay / connect_timeout / pgood_delay and some informative (device specific)problem descriptions ( as comments) in the file : common/usb_hub.c ...many possibilities to manipulate delays / max retries / force resets or whatever, even the log message: "Maybe the USB cable is bad?" is interesting ;-)... I would consider to "force" the King of USB to read this file contents (usb_hub.c + usb.c): So consequently I quietly step out of the discussion again and put HPS to CC :-) lol Regards Klaus