blood

So I don't know exactly what is wrong with the latest posted clearfog images (other than the u-boot.sata binary doesn't work), but after using the process I detailed above, I just let apt upgrade everything - including the kernel to 6.6.63-current-mvebu) and so far everything seems to be working after a reboot. I might get this back into production as my home router today after all once I run a few more smoke tests!

I should have mentioned, the above output came from using an old u-boot.sata that I rescued off my old install. When I used the one included in the new build, I didn't get any console output from uboot at all. I have since reverted to an older image from the archive (Armbian_23.11.1_Clearfogbase_bookworm_current_6.1.63.img). Using its u-boot.sata I also got no console output, but with my older one, I have been able to at least get this image to boot! So there's a recipe at least for getting something somewhat modern (if you consider an image that's over a year old "modern" - and from where I'm coming from I do!). Do I dare try to move its kernel forward? Or should I just settle with what I have and move along... I'm attaching a copy of the older u-boot.sata file that is working for me in case it's useful to anyone else. Oh, who am I kidding - this is a really old board and nobody is using them now. u-boot.sata

When I attempt to boot I get: U-Boot SPL 2018.01-armbian (Feb 17 2023 - 23:33:49) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | USB3 HOST0 | | 5 | 0 | SGMII2 | -------------------------------- PCIe, Idx 1: detected no link High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.29.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR3 Training Sequence - Ended Successfully Trying to boot from SATA AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Found 1 device(s). U-Boot 2018.01-armbian (Feb 17 2023 - 23:33:49 +0000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) MMC: mv_sdh: 0 AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Found 1 device(s). *** Warning - bad CRC, using default environment Model: SolidRun Clearfog Board: SolidRun ClearFog Base SCSI: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Net: Warning: ethernet@70000 (eth1) using random MAC address - d2:63:b4:30:b5:09 eth1: ethernet@70000 Warning: ethernet@30000 (eth2) using incremented MAC address - d2:63:b4:30:b5:0a , eth2: ethernet@30000 Warning: ethernet@34000 (eth3) using incremented MAC address - d2:63:b4:30:b5:0b , eth3: ethernet@34000 Hit any key to stop autoboot: 0 scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: TS120GMTS420S Rev: V011 Type: Hard Disk Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) Found 1 device(s). Device 0: (0:0) Vendor: ATA Prod.: TS120GMTS420S Rev: V011 Type: Hard Disk Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) ... is now current device Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 82 ms (35.2 KiB/s) ## Executing script at 03000000 Boot script loaded from scsi 191 bytes read in 80 ms (2 KiB/s) 26870 bytes read in 143 ms (182.6 KiB/s) 10631265 bytes read in 295 ms (34.4 MiB/s) 8551104 bytes read in 253 ms (32.2 MiB/s) Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... Card did not respond to voltage select! mmc_init: -95, time 19 starting USB... USB0: Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 ** ethernet@70000 Waiting for PHY auto negotiation to complete................. TIMEOUT ! ethernet@70000: No link. ethernet@30000 Waiting for PHY auto negotiation to complete................. TIMEOUT ! ethernet@30000: No link. ethernet@34000 Waiting for PHY auto negotiation to complete. After this, the similar messages repeat for a while trying to network boot. What sticks out to me here is: Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... I don't know this well, but it seems like u-boot is trying to load the initial ramdisk before the kernel is started. On my functioning disk (based on an old Buster install) rather than those errors I get messages about the ramdisk, device tree, and then the kernel loads. So I suspect something is broken with the initrd.

I set about to update my clearfog base last night because it was a few Debian versions behind and I wanted to use some of the stuff in bookworm - and upon flashing the latest image along with the uboot sata, my board now will not boot at all when using this image - either when using it via an m.2 SATA drive or a microsd - and if I go back to my old SATA stick and boot off it, it continues to boot fine. Something seems to indeed be broken in the modern images! As it never seems to get past uboot, I'm going to try grabbing the uboot binary from my old install and see if it works any better.

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.