DavidFajardo Posted December 6, 2024 Posted December 6, 2024 I am just posting so I can keep track of this thread. 0 Quote
Werner Posted December 6, 2024 Posted December 6, 2024 3 hours ago, DavidFajardo said: am just posting so I can keep track of this thread. I suggest to use the "Follow" button instead. 0 Quote
Maurycy Posted December 6, 2024 Posted December 6, 2024 Finally working with Rolling release. 0 Quote
Tomogo Posted December 6, 2024 Posted December 6, 2024 Hi, I have still problems also with rolling release so I'm using one older kernel with vmlinuz-6.1.75-vendor-rk35xx. 0 Quote
Maurycy Posted December 10, 2024 Posted December 10, 2024 Hi, I was too optimistic, the problem persist with rolling release. I rearranged power supply for the drives so now they are not supplied from one line- it didn't solve the issue. 0 Quote
Igor Posted December 10, 2024 Posted December 10, 2024 2 hours ago, Maurycy said: the problem persist with rolling release. Release is not a warranty that all bugs get fixed. That process takes several years and new bugs are keep getting introduced ... proper maitainances keeps this low. Here https://github.com/armbian/linux-rockchip/commits/rk-6.1-rkr4.1/ you can monitor what is getting merged. Rolling update just ships this few hours after merge is made in automatic way. 0 Quote
DavidFajardo Posted December 12, 2024 Posted December 12, 2024 Ok sir, I will keep it in mind next time. 0 Quote
Tomogo Posted December 12, 2024 Posted December 12, 2024 I don't know if this can help, but here are differences between not working and working kernel config config-6.1.75-vendor-rk35xx: config-6.1.75-vendor-rk35xx.diff.txt 0 Quote
Igor Posted December 12, 2024 Posted December 12, 2024 1 hour ago, Tomogo said: I don't know if this can help, but here are differences between not working and working kernel config config-6.1.75-vendor-rk35xx: Sadly the problem is a lot more complex Somewhere around PCI bus signaling / initialization / devices comm (tl;dr;) 0 Quote
Tomogo Posted December 12, 2024 Posted December 12, 2024 (edited) OK, so if anybody want working kernel it can be downloaded on my web pages: https://files.tomogo.cz/rock/linux.tar.gz Edited December 12, 2024 by Tomogo 0 Quote
Maurycy Posted December 26, 2024 Posted December 26, 2024 @Tomogo: SATA works great with the kernel provided. I really hope that it will be accesible in normal way. Now switching kernel and installing ZFS is doable but painful. My concusion: If someone want's OMV, I recommend DELL SFF Intel 6100T based unit. It is cheaper (used), uses less power (5W with the same amount of discs) and works. I had been using it for some time. Thanks! 0 Quote
Krishna0 Posted December 26, 2024 Posted December 26, 2024 Hi, I am using the same board but I am planning to connect a RAID card which is LSI Broadcom SAS 9300-8i. When I connect the card through the NVME slot, the board is not getting recognized. Should I install any drivers for the card? 0 Quote
Maurycy Posted December 28, 2024 Posted December 28, 2024 Afaik adding something to arm device is quite complicated as there is no bios like solution. Device first needs to be in device tree overlay to be seen by the kernel. 0 Quote
buhtux Posted January 5 Posted January 5 (edited) On 12/26/2024 at 5:33 PM, Krishna0 said: Hi, I am using the same board but I am planning to connect a RAID card which is LSI Broadcom SAS 9300-8i. When I connect the card through the NVME slot, the board is not getting recognized. Should I install any drivers for the card? Hi, based on my experience you will need to flash the 9300-8i card into IT-Mode (Link). Please use x86 or amd64 system for the flashing process. IT mode works like HBA, it pass all connected drives directly to the system. Afterwards you can create RAID volumes with mdadm, zfs, btrfs. Edited January 5 by buhtux 0 Quote
Tomogo Posted January 15 Posted January 15 Hi, has anybody info if the new official kerenl 6.1.84-vendor-rk35xx works fine with SATA disks? Thanks... 0 Quote
ypopovych Posted January 15 Posted January 15 (edited) I have the same problem on the latest rolling release kernel. Could be that this is not a PCI problem? I have a second controller in the m.2 e-key port with JMB582 and it works fine. Also I can see ASM1164 in the lspci output but without "ahci" driver loaded for it. I can enable disks if I do: echo "1" > /sys/bus/pci/devices/0001\:11\:00.0/remove sleep 1 echo "1" > /sys/bus/pci/rescan What can I do to help debug the problem? Edited January 15 by ypopovych added how to enable disks after boot 0 Quote
eselarm Posted January 16 Posted January 16 I had to look it up: https://docs.radxa.com/img/rock5itx/rock5itx-system-block-diagram.webp as I was not sure if it was on-chip (RK35xx) or extra. The latter is the case. On a Rock3A I also had success with m.2 e-key port with JMB582, but not used now, instead I use on-chip SATA via overlay. That makes make think that maybe for the Rock5ITX the ASM1164 kernel code is not compiled as module but in-kernel and so maybe there are timing issues in initialization at boot-up. There should not be, but that is what I would look at first as this is PCIe and we know there have been issues with it. If you do not need vendor kernel specifically, you might try 6.12 current/mainline. Also see/check what U-Boot the board boots with. 0 Quote
ypopovych Posted January 16 Posted January 16 I tried to install OS to the SATA SSD and connect it to the ASM1164 port to test. U-Boot detects SATA SSD, loads initrd, and then initrd fails to detect SSD and boot fails. It boots after 3-7 restarts and then works fine. Seems as U-Boot can initialize SATA controller properly and read data on every boot and kernel only one boot from five. 0 Quote
blood Posted January 19 Posted January 19 On 1/15/2025 at 12:54 AM, Tomogo said: has anybody info if the new official kerenl 6.1.84-vendor-rk35xx works fine with SATA disks? From what I'm seeing with the latest rk35xx vendor kernel, SATA is mostly broken once again (the SATA controller PCIe device is not detected and thus no drives attached to it). It seems to be a timing issue as occasionally they have showed up though. Also, zfs-dkms results in an actually broken system when used with this kernel; kernel oops on boot. I of course don't blame Armbian for this, but the rk35xx vendor kernel branch seems to be a hot mess. Too bad it's effectively required to use the VPU... 0 Quote
Werner Posted January 20 Posted January 20 10 hours ago, blood said: but the rk35xx vendor kernel branch seems to be a hot mess. It is. We made the best possible support from it. Each new sdk version brings fixes but also regressions. Though you actially have to give credit to rockchip for their rk35xx sdk. We had way worse in the past, not necessarily from rk but others like aml or aw. In comparison its surprisingly good Anyway it will take another few years until it is close to feature-complete in mainline. I think rk3399 still hasn't all its features mainlined but overall it is well matured now. You always have to keep in mind that some smart person have to sit down and write drivers for sometimes poorly, sometimes not at all, documented features of a soc. Either being paid to do so or being an enthusiast where latter are very very rare people and their efforts are often strongly under-appreciated. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.