I’ve got a pi5 and built my own rockstor image since it’s still experimental, but even though it boots, I’m having issues with the radxa penta sata hat attached. I’ve followed instructions from docs and have these overlays:
dtoverlay=pcie-32bit-dma-pi5 dtparam=pciex1
but the drives don’t get identified: ata4.00: qc timeout after 30000 msecs (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
I’ve tried default kernel(7.1) and lts/longterm kernel(6.18) on tumbleweed and have the same results in log. Raspberry pi linux kernel(6.18) on debian works as expected.
I wonder if this pr on the raspberry pi kernel could help since 6.18 kernel there works and has the drives show up. raspberrypi/linux#7393 Either way, something isn’t right with the jmicron controller.
Seeing as this is the most popular sata hat I’ve seen for the Raspberry pi as a nas, a good OOB experience(or at least easy workaround) would be helpful.
@eyecreate welcome to the Rockstor community (and thanks for transferring this thread from the github repo to the forum).
quick question - where did you add the overlay information in the file tree? I found that on the TW image that I built, it’s the one located in /efi/firmware/ Did you add those lines directly to the config.txt there or used the construct of e.g. include extraconfig.txt in the config.txt file and then placed those two lines in the extraconfig file?
So, both of those were located in the /efi/firmware directory (just for my own education)?
Since we’re following the upstream OpenSUSE packages/setups, there are not simple options to pin the kernel (and considering that the rpi and or debian kernels are compiled differently than the OpenSUSE ones). Unfortunately, the openSUSE rpi5 adaptation has taken much longer than on other Linux flavors.
Agree with the OOB experience and including it directly (or provide a workaround) would be great. Unfortunately, since I don’t own a SATA hat like this (at last not yet), I can’t figure out more on this.
Have you posted in the community forums around raxda to see whether maybe has tried that with an OpenSUSE rpi flavor?
A little more research, not sure it will do anything, but debian (and of course rpi linux) load the information a bit different than OpenSUSE (which is using the U-Boot architecture/process). Can you check whether 32-bit width can be forced by adding a kernel parameter to the GRUB_CMDLINE_LINUX_DEFAULT: either the ahci.override_dma_mask=1 or ahci.dma_bits=32 (to stay closer to the recommendation above) parameter.
nano /etc/default/grub
Then regenerate grub and reboot? grub2-mkconfig -o /boot/grub2/grub.cfg