Thanks for pointing to that article from Tom’s hardware which also links to a similar
text from the foundation
However, point 3 from @pimpek agreeing that booting directly from the sata hat is a legitimate
request at the manufacturers of these hats and this problem does not get solved by booting
from an usb disk not attached to the hat.
BTW: I do not understand why the power of the SATA-disks gets switched on/off on the hat,
because switching off the drive motors would be possible by hdparm commands…
This IMHO was additional cost without any real use!
Theoretically you could hardwire the GPIO pins that pilot the disks to 3V3. In the code change the GPIO config to INPUT instead of OUTPUT.
Just an idea, haven’t tested this.
@pimpek:
It is a shame that Seedstudio does not at all care for their paying customers.
Maybe some lucky day the truth about the non existing customer care of Seedstudio gets known and a competitor with decent supports takes over…
I had a 20 minutes of hope, I was thinking using a usb 3 hub could lead to a “not so bad” solution to get the ssd boot (by using usb A - A cables with a usb 3 hub on 1 rpi port, and booting a usb enclosed ssd on the second port). Unfortunately, it’s a no way, usb ports of the hat aren’t recognized by the system if not using the provided usb bridge.
Maybe using a overlay could be a satisfiying answer, but after few days of research, I still didn’t find the correct guide to do so (almost all answers are about using a ramdisk as overlay, which is not what we want of course).
I also looked in bcache, IOEnhancer or other similar software stuffs, but bcache isn’t supported in rpi kernel without recompiling it (and I don’t have all the time required to learn to do that), and IOEnhancer seems not supported anymore…
Would be nice if we could have at least an easy way to use a SSD as overlay of the sd card rootfs !
You use $ sudo -E rpi-eeprom-config --edit
to edit the eeprom and add this to the bottom
[config.txt]
gpio=25,25=op,dh
gpio=26,26=op,dh
Then save and exit. This sets the gpio pin to be outputs and set to high in the eeprom then because of the 20 second time out for USB MSD devices there is enough time for the devices to power up and boot from. this is how my setup is now. ( I have the first get quad sata hat) but it really shouldn’t make a difference
Before rebooting you also have edit the /usr/bin/rockpi-sata/misc.py and remove turning disks off. If you have install the rockpi-sata service otherwise when you restart the rockpi-sata service it kills your system drive. I just commented out the set_mode low
The lights should turn on almost instantaneous if this doesn’t happen check your firmware version only the later versions of the firmware allow the [config.txt] section
Don’t copy the content of boot and root partitions to the hdd or ssd. It only worked for me if I dd the partitions from the SD card to the hdd. Don’t forget to change the PARTUUID in the cmdline.txt and in the fstab! The PARTUUID is NOT the same one as on the sd card even wenn you dd the partition.
If your not familiar with dd, you can use the sd card cloning software in raspberry pi os. For this you must have an spare sd card to boot raspverry pi os in desktop mode, start the sd card copy programm an copy the sd card from your server to the ssd or hdd.
Now the system is booting from the hdd which is part of the SATA HAT.
That was a hard piece of work!
Hi! I try to boot from an 3.5’’ hdd and the boot process starts with loading the kernel but than it stops without an error message.
What works:
Booting the system from USB 2.0 with my SD Card in an ordinary cardreader.
What dosn’t work
Booting from an hdd connected by the sata hat (When booting from SD the hdd is accessible as usual)
loading the kernel woks but then the process stops.
From time to time I get a Kernel panic. Dont know what makes the difference.
LED on the boot drive is on. LEDs of RAID-system is off
What I did
Updated the firmware of the JM561 controller (under linux because under Windows the flashing software couldn’t find the card)
created an hardware RAID 1 with the raid manager software (first tests are promising speed ~ 90MB/sec)
changed the boot order of the raspberry pi 4
copied the root system to an hdd
changed the configuration of the sata-hat as mentioned in post 18
changed the configuration of the location of the root filesystem in cmdline.txt and fstab (rootfs on hdd)
changed the way of configuration of the lroot filesystem from PARTUUID to UUID in cmdline.txt and fstab
Changed the SATA port of the boot device -> same result
tried booting the kernel from SD and rootfs from hdd -> same result, boot process stops, no error message
Thank you for your fine solution. I have been using RPI4 and Quad Sata Hat and very satisfied with it.
Recently, I recently changed the OS to Debian Bullseye from the RaspberryPi OS. Is there any way to enable GPIO25, 26 pins on the Debian OS? It seems there is no config.txt file on it.
(I’m new to Linux OS. I’m sorry if the level of the question was poor.)
@JKaw I would make sure after editing both files you reboot the Pi as instructed (with the existing boot SD or USB connected) so that the changes take effect. Shutdown the PI 4. Disconnect old boot device and power back on.
Hey @Craigp, thanks for the awesome finds and solution to this issue!
I followed your instructions and I finally made it to work. In my case, I can boot from an SSD attached to the HAT, but only once. Whenever I reboot or use the shutdown commands, the HAT fails to detect the drives attached to it (Greeted by the QR code and message that I need an OS). The only option I’m left with is to cut the power to the HAT from the barrel plug and re-seat it so it boots this way.
I don’t know why this is happening but any advice would be greatly appreciated!
I had similar behavior when the USB cable or when the GPIO connection was loose. Check both connections. Normally it should survive a reboot. I mean, if you shut down your Pi, you need to cut the power anyway. In order to boot afterward.
Hey @estebanium thanks for the advice. Will definitely give it a try. I’m using the provided bridge connector from the HAT for the USB ports. I will reseat both.
It could be the same issue as you did experience, but does it make sense that the the boot works every time on cold start, but then it doesn’t with warm boot? I can reproduce this behavior 100% of the time. There isn’t any “flakiness” in regards to boot behavior. Maybe I should also mention that the boot drive isn’t an SSD, it’s an NVME in SSD enclosure, which may add more layers of firmware boot bugs…but then again it works once and then it doesn’t.
I feel like I’m missing something as a config option, but I have followed the guide exactly as described and it wouldn’t have worked at all if I didn’t do it properly.
It could be possible, that the NVME and all those layers are responsible for this issue.
On the other hand, it could be an issue with your fstab, crypttab or your cmdline.txt. I run a headless Ubuntu Server on that HAT. A SSD, with the OS and three hard disks are connected. I only address all of my drives via UUID, instead of /dev/sdX. However, I did notice that if I connect the server to my USB-Switch, to get my keyboard working, the server will fail to boot, because it will not find the SSD. Long story short, there are a lot of possibilities, why it won’t work.
Hey @estebanium sorry for my late reply. Yesterday after work I re-seated/re-plugged everything from scratch. Unfortunately the issue stays, but after some tinkering I was able to obtain a useful error code.
I’m sharing some of the config files in the forum, maybe someone else has better eyes to see an obvious issue that I miss…it will be helpful for anyone with a similar issue in the future, I think…
I’m using the following boot loader: 0fc8fc8e from date: 2022/12/07
Finally, /boot/config.txt has the following uncommented lines: dtoverlay=disable-wifi dtoverlay=disable-bt dtparam=audio=on camera_auto_detect=1 display_auto_detect=1 dtoverlay=vc4-kms-v3d max_framebuffers=2 arm_64bit=1 disable_overscan=1 otg_mode=1 arm_boost=1 dtparam=i2c1=on dtoverlay=w1-gpio gpio=25,25=op,dh gpio=26,26=op,dh dtoverlay=i2c-rtc,pcf8563
I’m not encrypting the root partition so I don’t have crypttab. I found this, but it seems to fix an issue with boot rather than cause it:
I will be more than happy to get any advice for something that anyone thinks it shouldn’t belong in the config files, but I simply can’t see anything that’s not ordinary or normal. Again, any advice is appreciated and thanks for your time until now!
An update to the issue. Got a brand new Samsung EVO 860 drive, dd’ed the old NVME to to it, same result - cold boot = no problems, restarting = cannot find boot partition and constantly changing between USB MSD and card reader with no result.
Considering using SD card with just /boot options and no rootfs - not sure if it will work as I intend to but it’s work in progress…
Thanks all for the suggestions!
