Raspberry Pi Forums

Every since I added a 2.5" Seagate drive to my Rpi 4 4GB, I haven't been able to reboot it w/o unplugging the hub. The web says the 'cheap hub' is back feeding. I bought a short USB3 extension cable and cut the red (power) wire to make a power condom for my hub.

Well that didn't cure the problem. I do a shutdown -r now, the green light flickers for a while, the red light stays on. Video goes away and the rpi4 sits with just the red light. Pull the usb cable out and put back in, and instantly the green light flickers and the board boots back up.

I bought this as a package off of Amazon. Package marketed by Canakit, it has their 5.1v 3.5amp power supply.

My powered usb3 hub is made by iogear GUH304P.
The drive that is powered by the usb3 hub is a seagate 2n1ap5-500 2TB
I did an apt-get update, apt-get full-upgrade to catch up on the software.

$ dmesg | grep Rasp
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1


I'm running tvheadend on this pi, as long as I don't reboot it it works great.

What should I do/check next?

Thanks,

If you have a 3.3v-serial-to-usb-adapter-cable, setting BOOT_UART=1 in the bootloader config and watching what's happening in the bootloader might yield some useful information.

If you don't remove the power feed to the Pi - which you aren't, since you're just trying to reboot - then whether or not the hub back-feeds power to the Pi is irrelevant.

It seems more likely that the Pi is waiting for a reply from the drive, and unplugging the hub tells the Pi that the drive is no longer available.
To prove / disprove that, when the reboot doesn't happen, rather than unplugging the hub from the Pi, unplug the drive from the hub

IIRC the problem isn't backfeed on the power line, it's backfeed on one of the data lines.

USB devices are only supposed to pull up the data lines when VBus is powered, but some ignore this, apparently this leaks enough power into the Pi to stop the PMiC resetting properly.

@plugwash you indicated that 'some ignore this', I have tried numerous powered usb 3.0 hubs of different makes/chipsets/price
and I have yet to find one that does not do this and stop Pi from resetting the PMiC (when power is applied to the hub).
Are you able to supply the make and model of a powered USB 3.0 hub that has been tested and actually follows the rules to allow
the PMiC to operate correctly ?
I am sure we would all be interested in getting one that works with external power .....
Maybe Pi should produce one (AKA the USB 2.0 one that was created some time back) that would work correctly.

RonR wrote: ↑

Fri Jun 26, 2020 9:11 pm

If you have a 3.3v-serial-to-usb-adapter-cable, setting BOOT_UART=1 in the bootloader config and watching what's happening in the bootloader might yield some useful information.

I have a couple of them. I'm not having luck figuring out how to change the boot loader config.

I tried using a xcellon SH7-5h2hc hub that has worked fine on my win10 box. I couldn't get the rpi4 to boot so I went back to the iogear hub that one amazon review describes as seriously flawed. I have seven raspberries across the spectrum that haven't given me any problems until I tried to run a hhd. Frustrated.

Szumi wrote: ↑

Sat Jun 27, 2020 5:24 pm

I'm not having luck figuring out how to change the boot loader config.

Run 'rpi-eeprom-update -h' and the instructions for altering the bootloader config will be displayed.

RonR wrote: ↑

Sat Jun 27, 2020 6:05 pm

Szumi wrote: ↑

Sat Jun 27, 2020 5:24 pm

I'm not having luck figuring out how to change the boot loader config.

Run 'rpi-eeprom-update -h' and the instructions for altering the bootloader config will be displayed.

I used sudo raspi-config after I posted.

I had to load some new drivers for my w10 box to get the serial console using putty.

My sessions

Last login: Sat Jun 27 13:50:53 EDT 2020 on tty1
Linux Rp4-1 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

pi@Rp4-1:~$ [ 882.343621] reboot: Restarting system
▒t▒n▒<▒▒¢▒▒{+Δ▒▒▒OF▒▒x7▒
Raspbian GNU/Linux 10 Rp4-1 ttyS0

Rp4-1 login: pi
Password:
Last login: Sat Jun 27 14:06:29 EDT 2020 on tty1
Linux Rp4-1 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

pi@Rp4-1:~$ shutdown -r now
pi@Rp4-1:~$ [ 54.705965] reboot: Restarting system
▒▒â▒<▒▒¢▒<


I issued the shutdown -r now first from a vnc connection and then from the serial console using putty. What you see above is what I saw. I had to pull the usb cable out of the pi to finish the boot process.

It appears you didn't get the bootloader config updated.

Run 'vcgencmd bootloader_config' and verify that you see 'BOOT_UART=1':

The bootloader output on the serial port should look something like this on an initial boot:

RonR wrote: ↑

Sat Jun 27, 2020 6:33 pm

It appears you didn't get the bootloader config updated.

Run 'vcgencmd bootloader_config' and verify that you see 'BOOT_UART=1':

You are correct. Bed time for me is near. I'll try again tomorrow. Thanks.

Okay, I think I got it this time.


$ vcgencmd bootloader_config
[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41


Did a shutdown -r now


Raspbian GNU/Linux 10 Rp4-1 ttyS0

Rp4-1 login: [ 244.229225] reboot: Restarting system

PM_RSTS: 0x00000020
RPi: BOOTLOADER release VERSION:c302dea0 DATE: Jun 15 2020 TIME: 14:36:22 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1592228179 0x53c64e47 0x00c03111
uSD voltage 1.8V
GLOBAL_RESET: 01 0

##### Hangs at Global_Reset until I pull and insert usb connector to hub###

PM_RSTS: 0x00001000
RPi: BOOTLOADER release VERSION:c302dea0 DATE: Jun 15 2020 TIME: 14:36:22 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1592228179 0x53c64e47 0x00c03111
uSD voltage 3.3V
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200
Boot mode: SD (01) order f4
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
CID: 001b534d474434515430941e53280131
CSD: 400e00325b590003b9ff7f800a404000
SD: bus-width: 4 spec: 2 SCR: 0x02c58003 0x00000000
SD HOST: 250000000 CTL0: 0x00000f04 BUS: 50000000 Hz actual: 41666666 HZ div: 6 (3) status: 0x1fff0000 delay: 2
MBR: 0x00002000, 4607043 type: 0x0c
MBR: 0x00466c43,245470141 type: 0x05
MBR: 0x00000000, 0 type: 0x00
MBR: 0x00000000, 0 type: 0x00
lba: 8192 oem: 'mkfs.fat' volume: ' RECOVERY '
rsc 32 fat-sectors 4496 c-count 574752 c-size 8 r-dir 2 r-sec 0
PM_RSTS: 0x00001000
Partition: 0
lba: 8192 oem: 'mkfs.fat' volume: ' RECOVERY '
rsc 32 fat-sectors 4496 c-count 574752 c-size 8 r-dir 2 r-sec 0
Read recover4.elf bytes 760544 hnd 0x000842a3 hash 'a0df2054a6721452'
Missing/empty 'fixup4rc.dat' continuing
0x00c03111 0x00000000 0x00000000
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting recover4.elf @ 0xcfa00200 partition 0


PM_RSTS: 0x00001034
RPi: BOOTLOADER release VERSION:c302dea0 DATE: Jun 15 2020 TIME: 14:36:22 BOOTMODE: 0x00000006 part: 6 BUILD_TIMESTAMP=1592228179 0x53c64e47 0x00c03111
uSD voltage 3.3V
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200
Boot mode: SD (01) order f4
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
CID: 001b534d474434515430941e53280131
CSD: 400e00325b590003b9ff7f800a404000
SD: bus-width: 4 spec: 2 SCR: 0x02c58003 0x00000000
SD HOST: 250000000 CTL0: 0x00000f04 BUS: 50000000 Hz actual: 41666666 HZ div: 6 (3) status: 0x1fff0000 delay: 2
MBR: 0x00002000, 4607043 type: 0x0c
MBR: 0x00466c43,245470141 type: 0x05
MBR: 0x00000000, 0 type: 0x00
MBR: 0x00000000, 0 type: 0x00
lba: 8192 oem: 'mkfs.fat' volume: ' RECOVERY '
rsc 32 fat-sectors 4496 c-count 574752 c-size 8 r-dir 2 r-sec 0
PM_RSTS: 0x00001034
Partition: 6
EBR: 0x00466c43 0x000013bd, 65534 0x000113bb, 524288 signature: aa55
EBR: 0x00477ffe 0x00000002, 524286 0x000913bb,244875266 signature: aa55
MBR: 0x00000002, 524286 type: 0x0c
lba: 4685824 oem: 'mkfs.fat' volume: ' boot '
rsc 32 fat-sectors 4033 c-count 516188 c-size 1 r-dir 2 r-sec 0
Read config.txt bytes 1855 hnd 0x00000005 hash 'd3de0e91ba612ff8'
recover4.elf not found (6)
recovery.elf not found (6)
Read start4.elf bytes 2272992 hnd 0x00062d80 hash '319662b44a4c80d5'
Read fixup4.dat bytes 5405 hnd 0x00067901 hash '0c1a6c6f96114a3f'
0x00c03111 0x00000000 0x0000001f
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting start4.elf @ 0xfec00200 partition 6


Raspbian GNU/Linux 10 Rp4-1 ttyS0

Rp4-1 login:

Szumi wrote: ↑

Sat Jun 27, 2020 11:45 pm

Did a shutdown -r now


Raspbian GNU/Linux 10 Rp4-1 ttyS0

Rp4-1 login: [ 244.229225] reboot: Restarting system

PM_RSTS: 0x00000020
RPi: BOOTLOADER release VERSION:c302dea0 DATE: Jun 15 2020 TIME: 14:36:22 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1592228179 0x53c64e47 0x00c03111
uSD voltage 1.8V
GLOBAL_RESET: 01 0

##### Hangs at Global_Reset until I pull and insert usb connector to hub###

The Jun 15 2020 bootloader cuts the USB power briefly when it's initializing and has caused others to have reboot problems similar to yours.

You might try disabling this behavior by adding the following line to the bootloader configuration:

It didn't change behavior.


pi@Rp4-1:~ $ vcgencmd bootloader_config
[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
USB_MSD_PWR_OFF_TIME=0

Burngate wrote: ↑

Sat Jun 27, 2020 11:00 am

If you don't remove the power feed to the Pi - which you aren't, since you're just trying to reboot - then whether or not the hub back-feeds power to the Pi is irrelevant.

It seems more likely that the Pi is waiting for a reply from the drive, and unplugging the hub tells the Pi that the drive is no longer available.
To prove / disprove that, when the reboot doesn't happen, rather than unplugging the hub from the Pi, unplug the drive from the hub

Unplugging the drive from the hub doesn't do anything.

Thanks,
Szumi