blood

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...

@Werner Thanks for the attention and advice. I've read plenty of your posts in the past and your contributions are really appreciated! Does Armbian have a support path back upstream to Radxa for their vendor kernel? It always takes at least two parties to have an incompatibility so I'm not sure where the ultimate fault lies between ZFS and RK35xx here, but perhaps Radxa could help some here. I know this is the community supported Rockchip forum, but the Rock 5 ITX board is actually in the platinum support category (my fault for misfiling this but I assume it effects all rk35xx boards) which I assume means there's some linkage back to the vendor (but maybe I misunderstand what platinum support really means). In this case, I'm booting and running my root filesystem off of emmc which is soldered onto the board. I'm flashing Armbian to it over USB using rkdeveloptool via maskrom - which means I can't pull the storage and read it on another system unfortunately. I guess I could reinstall to an SD card (or move my root FS to removable storage for a future install) but I'm not there right now. @Turbodid If you have any luck or even just a different experience with this or other approaches, please make sure to update this thread.

I'm using a Rock 5 ITX and noticed after installing the latest rk35xx kernel image (6.1.84-vendor-rk35xx) that my system wasn't booting. So I connected to the debug console and observed a kernel oops being emitted. It dumps out a few pages of data, but the initial messages and call trace are: I have all the hex data if someone would use it but it doesn't seem worth including here. The boot flounders around in systemd for a bit but never gets to a login prompt - and I'm not that savvy with uboot to enter single user mode or otherwise dig in more. So I reinstalled from nothing, upgraded all my packages (including the vendor-rk35xx kernel), rebooted, and everything was ok - until I installed zfs-dkms and built the zfs module and rebooted - at which time I got back into the same busted position. And that's where I am now. I suppose I could go without zfs but I've been using it for a couple decades now and prefer it over the alternatives. As I'm not doing anything critical with this system yet, I don't mind futzing around and providing data or otherwise helping to debug what's up. At least for a few days. It does run my jellyfin instance, but I have plex running on another system so I'm too put out. A few months ago something similar (but different!) occurred after a rk35xx kernel upgrade but in that case, the system would at least boot to a login prompt eventually where I was able to downgrade the kernel and get it working again - and then the next version of the package fixed the problem. But in this case, it is effectively bricking the system for me (I'm sure someone that knows more about uboot could interrupt the boot and maybe recover things) to where I just reinstall - but that's not a good way to iterate and test fixes. I run the rk35xx vendor kernel because jellyfin has support for hardware transcoding when using that kernel - and as far as I know it does not when running against mainline - but this vendor kernel seems to be... less than stable! Any advice?

I have a Clearfog Base but not a Pro - but I utilized the instructions here and have been running Armbian off a SATA m.2 stick for years now without issue. When I attach to the USB console and boot I begin to get console output immediately, first from the firmware, then from uBoot, and finally from the kernel and into userland. Can you share the end of the output that you see? Does it go as far as "Starting Kernel" (or similar, I forget exactly what it says). My first suspicion is that the img (not an ISO per se but I know what you mean) wasn't written to the block device in the manner the board is expecting and so the handoff to the boot loader isn't happening. Do you have a SATA m.2 to USB adapter that you could use to write the image to the media from another system? I'm pretty sure when I set mine up that's what I did rather than writing the image to the SATA drive from within the Clearfog itself (that was booted off SD).

Has anyone made (or bought!) an adapter that takes the 3 pin TTL-level console port and converts it to a DB9 or RJ45 port that can mount in a PCI bracket? If so, what did you use? And what port did you use to power it as the console port does not provide a 3.3V or 5.5V pin for power (there is a pin labeled "RSV" which seems to supply 5V and may be usable but I don't know its capabilities). I've done this before for other systems using these without too much trouble but when I tried with this board it's not working. Admittedly I haven't hooked it up to a scope to look at the signals, but I'm suspicious of the high baudrate being to blame. I have a couple USB adapters that work (so I know the console itself works), but I want to rackmount this box and wire it up to my console server. I need RS232 to do that.