USB-MSD boot fails after soft reboot (WD Elements 25A3) #241
Comments
|
Setting netconsole soft reboot (working w/ pwr_off_time=0) |
|
With netconsole soft reboot (looping w/ pwr_off_time=250) |
|
With netconsole soft reboot (working w/ pwr_off_time=5000) |
|
|
|
I saw I tried first with netconsole soft reboot (retry loop; pwr_off_time=1000; xchi_debug=0xf)So then I tried again (unplug power to cold boot successfully, then netconsole soft reboot (stuck; pwr_off_time=1000; xchi_debug=0xf)Next I flashed netconsole soft reboot (stuck; pwr_off_time=1000; xchi_debug=0x3f)at this point its stuck again (the same way it is soft-rebooting with anything lower than |
|
The drive seems to fail to respond to a READ request after a soft-disconnect. It might be worth verifying USB disconnect behaviour by booting from SD then repeatedly connecting and disconnecting the USB cable from the Pi (but not touching the enclosure) to verify that the drive is always detected. |
|
Please could you give this experimental bootloader a try by using the Raspberry Pi Imager to flash the image to a spare a spare sd-card. rpi-eeprom-recovery-2020-10-23-msd-hdds.zip This software has not been fully tested and whilst you can just revert the bootloader back to the normal production release using the Raspberry Pi Imager I recommend not using this with any data that you can't restore from a backup. |
This was referenced Oct 23, 2020
I gave this a shot. Copied onto FAT partition on a fresh SD card. Booted up, I see the screen turn green and the green light flashing. Then I remove the SD card and boot but it still says "bootloader: c305221a Sep 3 2020" and showing my 1500ms timeout from before. |
|
Okay apparently if I use macOS Disk Utility's erase feature and select GPT it doesn't work. Redoing with MBR resulted in the same green screen, but subsequent reboot shows Oct 23 2020 and back to 1000ms timeout. I see additional logging now as well, so will rerun my previous soft-reboot tests now. |
|
It works. The soft reboot is extremely fast, as-if it is not waiting around any longer. I barely see the bootloader on my screen. netconsole test eeprom (cold boot + usb hotplug)netconsole test eeprom (soft reboot)I captured the logs above with 0xf, but am happy to redo with 0x3f if you would like. Overall this seems to work spectacularly, with much faster boot times than what I was seeing before. I would be curious to hear more about what changed. |
|
During a reboot USB port power might go briefly causing problems for USB devices. The workaround for this is to make it go off for a long time (at least 1 second) to look more like a manual disconnect and let the USB hardware get itself into a good state. On Pi 4B rev 1.3 or older (2GB, 4GB) the xHC must be initialized in order to control the USB port power. The bootloader initializes it, turns off USB port power, waits a second then powers on and resumes. Whilst this generally works it seems that some USB-SATA or HUB chips will get stuck if USB port power off happens to early. The change is to start regular device enumeration and then do the power off whilst trying not to increase the overall time. The soft-reboot will be faster because it's avoiding the downstream HUB / USB-SATA getting stuck and timing out. There are also some other performance improvements to reduce the overhead of the HDMI display. If you look in the EEPROM config then HDMI_DELAY is set to zero. If you comment that out then it won't even enable the display unless booting is getting stuck. Thanks, for the detailed feedback. There's a bit more testing, reviewing and integrating to do for other features but I hope to release this as beta fairly soon. |
|
Appreciate the explanation! I have another drive (a Seagate STHN2000400 Backup Plus Slim 2TB) that I have been using with my development RPI4, and I generally soft-reboot it atleast a dozen times a day. It has been very reliable, but today with the Sep 3 2020 firmware it got stuck in bootloader after a soft-reboot. At the same time, the light on the drive was blinking rapidly. I'm not sure I will be able to reproduce it again, but if I do I will try to get the netconsole logs. I imagine, though, the new firmware will make these types of soft-reboot lockups a non-issue. |
|
This should now be fixed in the slightly more official pieeprom-2020-10-28 beta release. N.B. There's a couple of other larger changes pending before this makes it to stable. |
|
I also have this issue and reassuring to this this being identified and (hopefully) fixed in future firmware. Crucial BX500 - SSD - This is the main boot disk (with this cable). Just tried too |
|
Update: Installed the |
|
Closing bug as reported by tmm1 |
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I have a WD Elements 12TB drive that I am using to USB boot my PI4. Everything works great until I soft-reboot, at which point the eeprom gets stuck somewhere.
To Reproduce
Steps to reproduce the behavior:
systemctl rebootScreenshots
Bootloader version and configuration
USB boot:
lsusb -vvv
netconsole cold boot (working)
netconsole soft reboot (hung)
Additional context
I'm working on a project trying to boot RPI4 using off-the-shelf large-capacity USB drives. Similar problems have been seen with other drives such as a Seagate STEB6000403 6TB (I can get lsusb for that one as well).
I know there are several usb related timeouts, which I am now going to start playing with to see if I can get this particular WD to boot. But my goal is to not have to tweak timeouts for every drive, so I'm happy to gather as much information here such that the defaults can be improved to support a wider variety of hardware.
The text was updated successfully, but these errors were encountered: