[INFO] SSD + Enclosure Doesn't power on after reboot

[himuura]

For general boot questions please check the read the Boot Problems sticky post on the forums.

N.B The bootloader does not persist in memory and if the rainbow splash screen has been displayed the issue is likely to be in the firmware or Linux. If so, it's better to target the bug in the Firmware or Linux repositories first e.g. NFS, USB or dmesg logs would be Linux issues.

Describe the bug
Pi doesn't force SSD enclosure to power on (have to manually press the case power button)

To Reproduce
Steps to reproduce the behavior:
Simple reboot.

Expected behaviour
A clear and concise description of what you expected to happen.
Maybe fine tune of usb power off ports so it doesnt affect the usb boot drive.

Screenshots
If applicable, add a photograph of the bootloader HDMI diagnostics screen.

Bootloader version and configuration
If you have modified the default bootloader release or configuration then please attach the bootloader configuration (vcgencmd bootloader_config) and version (vcgencmd bootloader_version)
vcgencmd bootloader_version
Jun 15 2020 14:36:19
version c302dea096cc79f102cec12aeeb51abf392bd781 (release)
timestamp 1592228179

vcgencmd bootloader_config
[all]
BOOT_UART=0
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

SD card boot (please complete the following information):
Raspbian OS with latest stable, booting from Kingston A400 SSD and Inateck enclosure FE2013 (ASM1153E chip).

USB boot (please complete the following information):
For issues booting with specific USB devices please verify that the system boots from an SD-card with the same devices connected and attach the results of 'lsusb -vvv'. This helps to rule out USB HUB power issues.
In the beta release it's likely that a UART or NetConsole boot trace will be required.

Additional context
Don't actually know if this is a bug or feature, since it's an issue with the enclosure itself and not the Pi. If anyone has an idea on how to bypass this, please feel free to reply. it's annoying having to manually power on the boot drive in every reboot. My other Pi drive is constantly powered on though...(yes, both connected to 3.0 ports).

[timg236]

Please can you upgrade to the latest beta release 2020-07-06 and verify whether the problem still occurs. This sounds like a duplicate of a recently closed Issur

[himuura]

Im terribly sorry mate! Will do! Thank you for your kindness!

[himuura]

Just the firmware or the *.elf and *.dat are also needed? Tryed the latest beta, didn't work. Still have to manually press the power botton on the enclosure to boot the ssd up.

[himuura]

Don't know if this helps:

Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x55aa Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
bcdDevice 1.00
iManufacturer 2 ASMedia
iProduct 3 asm1153e
iSerial 1 000000000001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0079
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Command pipe (0x01)
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x0000f41e
BESL Link Power Management (LPM) Supported
BESL value 1024 us
Deep BESL value 61440 us
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 2047 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x000d
Self Powered
U1 Enabled
U2 Enabled

[timg236]

You need to update the bootloader EEPROM version - it looks like #151
sudo apt update
sudo apt upgrade

Make sure /etc/default/rpi-eeprom-update is set to beta
sudo rpi-eeprom-update -a
sudo reboot

[himuura]

sudo rpi-eeprom-update -a

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTFS /boot
BOOTLOADER: up-to-date
CURRENT: seg jul 6 11:48:15 UTC 2020 (1594036095)
LATEST: seg jul 6 11:48:15 UTC 2020 (1594036095)
FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

All packages up to date. Didn't work though...

[timg236]

Ok. thanks. I think we'd need to see BOOT_UART debug logs to see if the USB port ever goes to the connected state. You could try experimenting with USB_MSD_PWR_OFF_TIME e.g. try zero

[himuura]

Ok, can you guide me through? i guess it's firmware editing, right?

[timg236]

btw We have one of these in the interop test kit which seems to work ok https://www.amazon.co.uk/Inateck-Enclosure-External-Supported-FE2002/dp/B00FCLG65U

[timg236]

BOOT EEPROM config changes are documented here https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

[himuura]

Will try them out. My enclosure is https://www.amazon.co.uk/Inateck-Drive-Enclosure-External-FE2013/dp/B075TXT3RZ/ref=sr_1_5?dchild=1&keywords=inateck+2013fe&qid=1594291136&s=computers&sr=1-5

[himuura]

[all]
BOOT_UART=0
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

Didn't work as well... Any other solutions?

[timg236]

I can't really tell without log information, it might be worth trying to connect this via a USB2 port or a HUB.

[lurch]

BOOT EEPROM config changes are documented here https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

Seems like that's missing USB_MSD_PWR_OFF_TIME ?

[himuura]

Haven't figure this one out yet. But it's something related to the power management of the USB ports. Got an Inatek Drive Bay (those that allow 2 disks, either sata 2.5 or 3.5) with it's own power supply and i have no issues with booting from there. But something weird happens when i send the shutdown command to the pi while plugged to the enclosure ssd: the ssd drive stays ON. While rebooting, the drive goes off and i have to manually press the power on button on the enclosure, when i shut it down, it doesn't go off. Kind of weird...

[timg236]

When Linux reboots (including halt) PCIe is reset which will also reset the VLI chip. The VLI reset does not change the USB port power state.

For HALT the VPU just sits in an idle loop waiting for a GPIO to wake. However, if POWER_ON_HALT is set then the PMIC outputs are set to off which will cause USB power to go off.

During USB MSD boot the bootloader initially powers of USB port power for 1 second (this can be increased or skipped) because some USB devices don't seem to like the brief period where the PCI is reset but USB is inactive. The workaround is to make this look like a full power off.

You could try increasing the power off time (up to 5 seconds) and also booting a Raspberry Pi from an SD card then hotplugging this enclosure. It should be detected WITHOUT requiring a button to be pressed on the enclosure. That should be equivalent to say a 5 second power off in the bootloader.

I'd need logs from the bootloader to diagnose that further, NETCONSOLE can be used instead of a UART (see bootloader config docs)

[timg236]

I've ordered one of the enclosures since it's readily available from Amazon. Looking at the reviews it seems that having to press the power button is a fairly common issue with other devices but I'll know more after booting it with traces.

[himuura]

appreciated mate!! thank you a lot for the help!

[ghost]

BOOT EEPROM config changes are documented here https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

Seems like that's missing USB_MSD_PWR_OFF_TIME ?

I've filed raspberrypi/documentation#1621 😉

[timg236]

Reboot works without pressing the power button with the latest Raspberry Pi OS and Jul 6th bootloader so long as USB port power off is disabled.
USB_MSD_PWR_OFF_TIME=0

Hot plugging this into Linux booted from a SD card also requires the power switch which indicates a flaw in the design of the power switch. USB devices are supposed to power when connected to the port without requiring an additional button press

[himuura]

that's weird...i tried the same firmware and it didn't work for me... Gonna try it again this afternoon, any advices?

[himuura]

well, tested it again now...and it WORKS!! dunno why, the only difference was instead of appending the USB_MSD to the end of the file, i inserted the option after the POWER_HALT.

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

Seems to be working now...How can i manage future updates now, since i have a "custom" .bin?

[timg236]

rpi-eeprom-update migrates the current bootloader config file from 'vcgencmd bootloader_config' unless you specify -d which skips that step and uses whatever settings were in the pieeprom.bin file i.e. you shouldn't need to do anything unless you use the Raspberry Imager to revert to factory defaults.

[himuura]

Will do! Thank you for all you help mate!! CLOSED

[timg236]

Thanks, for the re-test. One minor addition, you might see different behaviour with the 8GB board I'll add a comment if I find out what's different there. Closing bug.

[timg236]

The hardware power sequencing on the 8GB means that there is an unavoidable short power off during reset where VLI and PCI power is off.

With this enclosure a possible workaround was to short the power button or stick the button down.