Active threads

I've been working on getting Armbian running on an H96 Max RK3528 TV-box (board marking RK3528_DDR3_8X4_V12) with 4GB DDR3 and 64GB eMMC running stock Android 13. I'm building on Ilya Kurdyukov's work (github.com/ilyakurdyukov/rk3528-tvbox) and have made significant progress, but I've hit a wall and need guidance. WHAT WORKS 1. Flashed custom U-Boot (2017.09 Rockchip with Ilya's patches + my custom patches for USB host activation and USB-first boot) via rkdeveloptool. 2. Added patches to enable USB host in U-Boot DTS: &u2phy_host, &usb_host0_ehci, &usb_host0_ohci all set to status = "okay"; &usbdrd_dwc3 set to dr_mode = "host", status = "okay". 3. Modified distro_bootcmd so boot_targets = "usb0 mmc1 mtd2 mtd1 mtd0 pxe dhcp" — network boot is attempted before Android fallback. 4. Built Armbian image with BOARD=rk3528-tvbox, BRANCH=legacy, RELEASE=jammy, xfce desktop. 5. TF-slot does not work (box hangs when microSD inserted in TF slot, likely BootROM SD-boot disabled via OTP as @jock mentioned in other RK3528 threads). 6. USB card reader with microSD works in U-Boot — I see "U-Boot.armv8" DHCP client on my Mikrotik router at IP 192.168.55.114. 7. Set up PXE boot infrastructure: dnsmasq TFTP server on 192.168.55.228, NFS rootfs export on same server (/srv/nfs/armbian-rootfs), Mikrotik DHCP configured with next-server and boot-filename options. 8. U-Boot successfully downloads via TFTP: pxelinux.cfg/01-c6-33-00-3f-cb-3c (PXE config by MAC), Image (kernel, 34 MB), and dtb/rockchip/rk3528-android.dtb (extracted from stock Android boot.img, compatible: "rockchip,rk3528-evb2-ddr3-v10", "rockchip,rk3528"). WHAT DOES NOT WORK After TFTP downloads complete, the kernel appears to never start: — HDMI shows only grey screen (U-Boot logo from Ilya's gray_square_logo patch). — No kernel DHCP request on network (would indicate IP_PNP starting). — No NFS activity (nfsstat -s shows calls = 0). — No ARP responses from the box — only Mikrotik ARP requests to .114 appear in tcpdump. — Eventually Android fallback loads (boot_android runs after distro_bootcmd fails). EVIDENCE — NETWORK TRACES dnsmasq log confirms successful TFTP downloads: Apr 24 01:33:38 dnsmasq-tftp: sent /srv/tftp/pxelinux.cfg/01-c6-33-00-3f-cb-3c to 192.168.55.114 Apr 24 01:33:45 dnsmasq-tftp: sent /srv/tftp/Image to 192.168.55.114 Apr 24 01:33:45 dnsmasq-tftp: sent /srv/tftp/dtb/rockchip/rk3528-android.dtb to 192.168.55.114 Then complete silence from the box. tcpdump — U-Boot DHCP + TFTP sequence (this part works): 00:45:24.375253 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:33:00:3f:cb:3c, length 300 DHCP-Message: Discover, ARCH=22, Vendor-Class: "U-Boot.armv8" 00:45:24.878890 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:33:00:3f:cb:3c DHCP-Message: Request, Server-ID: 192.168.55.1, Requested-IP: 192.168.55.114, Vendor-Class: "U-Boot.armv8" 00:45:24.942243 IP 192.168.55.114.1583 > 192.168.55.228.69: TFTP, RRQ "pxelinux.cfg/01-c6-33-00-3f-cb-3c" octet timeout 5 blksize 1468 00:45:25.005127 IP 192.168.55.114.1646 > 192.168.55.228.69: TFTP, RRQ "uInitrd" octet timeout 5 blksize 1468 00:45:28.349357 IP 192.168.55.114.1918 > 192.168.55.228.69: TFTP, RRQ "Image" octet timeout 5 blksize 1468 00:45:35.412847 IP 192.168.55.114.2837 > 192.168.55.228.69: TFTP, RRQ "dtb/rockchip/rk3528-evb2-ddr3-v10.dtb" octet timeout 5 blksize 1468 All files transfer successfully (observed via TFTP ACK packets). tcpdump — after booti, everything goes silent. The only traffic about the box is Mikrotik's ARP probes: 00:55:19.283404 ARP, Request who-has 192.168.55.114 tell 192.168.55.1 00:55:20.296683 ARP, Request who-has 192.168.55.114 tell 192.168.55.1 00:55:21.346711 ARP, Request who-has 192.168.55.114 tell 192.168.55.1 00:55:23.441524 ARP, Request who-has 192.168.55.114 tell 192.168.55.1 ... continues for minutes with no response from the box ... The box does not respond to any ARP, does not send new DHCP, does not contact NFS (port 2049 or 111). It is as if the kernel never actually starts — or it starts but hangs so early that no network driver comes up. NFS server stats — zero kernel activity: $ sudo nfsstat -s Server rpc stats: calls badcalls badfmt badauth badclnt 0 0 0 0 0 Confirms the kernel never reached NFS root mounting. WHAT I HAVE TRIED Tested multiple combinations, all fail the same way: — 3 different DTBs: rk3528-evb1-ddr4-v10.dtb, rk3528-evb2-ddr3-v10.dtb, and the extracted Android DTB (which matches exactly: "Rockchip RK3528 EVB2 DDR3 V10 Board"). — 4 console configs: console=tty0, console=tty1, console=ttyFIQ0,1500000, and combinations. — With and without initrd (both uInitrd and no initrd). — USB card reader with microSD for rootfs (UUID-based mount). — NFS rootfs (CONFIG_ROOT_NFS=y confirmed in kernel config). — Various bootargs: earlycon=uart8250,mmio32,0xff9f0000, ignore_loglevel, panic=10, rootdelay=5. Current PXE config (last attempt): default linux timeout 10 label linux kernel Image fdt dtb/rockchip/rk3528-android.dtb append root=/dev/nfs nfsroot=192.168.55.228:/srv/nfs/armbian-rootfs,vers=3,tcp,nolock,rsize=32768,wsize=32768 rw ip=dhcp console=ttyFIQ0,1500000 console=tty1 earlycon=uart8250,mmio32,0xff9f0000 loglevel=8 ignore_loglevel panic=10 rootdelay=5 FILE VALIDATION All files check out: Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages ARM64 magic "ARMd" at offset 0x38 confirmed. DTB: Device Tree Blob version 17, correct compatible string. Kernel: CONFIG_NFS_FS=y, CONFIG_NFS_V3=y, CONFIG_ROOT_NFS=y, CONFIG_IP_PNP=y, CONFIG_IP_PNP_DHCP=y — all built-in. THE DIAGNOSTIC ROADBLOCK — UART I cannot use UART for debugging. My board has DEBUG pins marked (TX/RX/GND/VCC near the WiFi module) but UART output is pure garbage at every standard rate (115200, 460800, 921600, 1500000). I suspect either: the DEBUG pins are poorly soldered on this unit, the UART configuration is different from what Ilya documented, or the pins are actually for a different UART or purpose entirely. Without readable UART, I am completely blind to what happens after U-Boot's booti command — whether the kernel panics, hangs on early init, or starts silently. MY QUESTIONS 1. Is PXE/TFTP network boot actually expected to work on this U-Boot 2017.09 from Rockchip? The bootcmd_pxe in this U-Boot is: run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi Has anyone successfully booted Armbian this way on RK3528? 2. Is there a known issue where Ilya's U-Boot + Armbian kernel don't hand off properly? Is there a specific bootm/booti command format required that PXE might not follow? 3. Could the issue be that the Armbian kernel expects specific arguments (like androidboot.* or bootloader-specific init params) that my PXE append line does not provide? 4. Are there any known-working examples of Armbian RK3528 TV-box boot that do NOT rely on on-device storage (microSD/USB flash)? 5. Given that U-Boot runs and gets DHCP fine, all files transfer via TFTP fine, file formats are correct, but the kernel is silent after booti — is this a known class of problem with a known solution besides UART? BOARD DETAILS Model: H96 Max RK3528 (board RK3528_DDR3_8X4_V12) SoC: Rockchip RK3528 RAM: 4GB DDR3 (8x Samsung K4B4G0446B) eMMC: Samsung KLMCG2KETM-B041 64GB WiFi: SKYWB8800 (AIC8800) Stock: Android 13 (RZX.V01.20240924) MAC: C6:33:00:3F:CB:3C I'm happy to run any diagnostic commands or provide additional info. Thank you for any guidance.

Thanks, I compiled one myself too, and it works fine. I actually thought Nick A said A7S support was only added in 6.18. I also built a desktop version for A7S, but the GUI doesn't seem to start or work properly.

Aiee! Installed my old "Noble" image. Updating will remove kernel 6.18.18 and install 6.6.99 and also has the error in the firmware package as decribed above by @VBB. Also, that funny "cli.github.com/packages" repo does not work. While that kernel downgrade is probably caused by linux-image-current-spacemit moved from 6.6.99 to 6.18.x recently (and the Armbian repos are out of date somehow) that firmware package should update without any errors. Will need time to sort this out. Anyhow, the "Noble" image works with GPU-activated Gnome desktop as long as you do not update (downgrade)...

I published my Vontar H618 bring-up patch set here: https://github.com/aco-art/vontar-h618-armbian-patche It includes the Armbian userpatches, U-Boot/kernel changes, and diagnostics tools I used for this box. Tested on my 4 GiB DDR3 Vontar H618 unit and shared in case it helps with similar H618/H616-class TV boxes. On my tested unit, Wi-Fi, Bluetooth, LAN, HDMI output, and the basic GPU/display path are working with this baseline.

I'm having the same issue after upgrading. I do backups on an HDD via USB for the two drives on my HC4 I was on Bullseye this year and was planning on moving up to Bookworm for a bit, but was hit with the issue. I decided to jump then into Trixie in the hopes that a more recent kernel would fix it, but I'm still facing it. kernel: Linux odroidhc4 6.18.10-current-meson64 dmesg error msg: usb usb1-port2: connect-debounce failed

We don't ship headers for each and every trunk image. Way too much data. Simplest solution is to use the framework to create a complete set of kernel deb packages. Those will include matching headers.

The orange pi zero 2w is configured to only start u-boot from the microSD in the built-in microSD. You would have to: * recompile that uboot to load the initramfs and the kernel from your alternative storage (did you really mean HDD? which connector would you use?) or * load initramfs and kernel from the typical microsd /boot partition, but configure the kernel argument line to accept the HDD as the rootfs (make sure that the initramfs contains the kernel modules, and the hdd name is in the /etc/fstab file) or https://jamesachambers.com/orange-pi-zero-2-usb-ssd-boot-guide/

@lsdlsd88 hello! Thanks for sharing the photos and the serial logs; it looks like the stock firmware did not pick up the sdcard at all. The sdcard seems to be detected, but for some reason the rockchip miniloader of the stock firmware does not it as first source. Are you able to retrieve the first 100-200 megabytes of the original firmware via serial? You should be able to use dd even within Android. edit: ah-ha ok, I understand! there is misconfiguration in the webserver and the link changes; thanks, I updated it!

Yes, you can completely resize it. You can also turn it to ZFS volume, and boot off of it. Just rebuild u-boot with ZFS support. Or ask, and I will provide patches required to have it.

It is. Before I managed to rebuild u-boot with ZFS support, I had to boot off of EMMC. I shrunk first partition with kernel, initrd etc, and then made another one with actual FS. Temporary solution for me back then. But gave me time to rebuild everything and enable native ZFS boot. Since then, I use EMMC only as a ZFS volume (another one in the mirror is NVME drive). never used armbian-config though - I am old-schooler, so I had to build whole stack myself to get what I wanted.

I am using the same board, and I also experienced this. Sometimes USB is not re-enumerated. Also, if you're using USB-C, sometimes some wires requires you to flip the connector. Basically some makers are cheaping out on cables, and they work only when you flip it. Also, if you'll leave the drive connected and reboot, does it find it? Have you checked u-boot, does it see it? Be aware, that USB-C connector is finicky. I had to replace it (resolder with new, sturdier variant), and then make it concrete-hard to break by solidifying epoxy over and under it (keep connector connected in it, and put some oil on it before plugging it in, so that epoxy won't leak inside it.

Use armbian imager for flashing it, arduino flasher cli is not compatible

current_6.6.99_minimal (desktop build has the snd-usb-audio module)

@Vinicius Guastala Thank you for your feedback. Your patches have already been merged into my repository.

@KhanhDTP are you using esync of wine? NTsync is available on 6.18+ rk3588 kernels. I think that may give a performance improvement.

@Sergioclr You don't need patches to edit the kernel config: config/kernel/linux-sunxi64-legacy.config sicxnull already has this patch, but with a different name: drv-pwm-sun50i-h616-enhance-pwm.patch drivers-pwm-Add-pwm-sunxi-enhance-driver-for-h616.patch To add Zero2W Ethernet settings to your DTS, you can create your own patch using git commands: Run ./compile.sh Press Ctrl+C in the middle of the kernel compilation. Navigate to the directory: cd cache/sources/linux-kernel-worktree/6.6*/ Use the following commands: sudo git status sudo git add . sudo git commit -m "dummypatch" sudo pico arch/arm64/boot/dts/allwinner/sun50i-h313-x96q-lpddr3.dts sudo git add . sudo git commit -m "Fix Ethernet" sudo git format-patch -1 1 for the first commit (0001-Fix-Ethernet.patch)... 2 for the first and second commit (0002-dummypatch.patch) ) The first "add" and "commit" cleans the kernel of previous patches, leaving you with a clean, patched kernel. The format-patch command will create a patch in the root directory of the kernel. Copy it to your patch directory. For original Armbian kernel patches, you must add them to series.armbian and series.conf.

I have just turned my machines on today and now does the PWM signal on node 3 work, but it is still behaving weird. It is running around 3000 RPM with a pwm1 value of 3, where node 1 need a pwm1 value around 70. The pwm1 was working for 2 hours after that full speed I am currently focusing on fix node 3 (Healthy) which are running the same kernel as node 1 (Healthy) . I checked the dtb files using a sha256sum and that matched on both machines. I did also validate the kernel checksum which also match.

I want to give it a try on MeCool KM6 Deluxe, just started researching.

Thank you for any information... when I have more time I will try with the help of AI... because I don't have enough knowledge myself 🙂 regards

Using our XR expertise, Collabora created a standalone XR experience for our 1% for the Planet partner, SOMAR, to showcase the direct impact of underwater noise pollution on marine life. View the full article

You need to look into github changes then, everything is traceable, but certainly not an easy and quick thing to do.

rk3588-pcie_bifurcation_2x2-uboot.patchrk3588-pcie_bifurcation_2x2.patch Attached are two patches I've prepared. One for uBoot (to correctly recognize split pcie3x4 to two independent controllers, pcie3x4 and pcie3x2), and one for DT of NanoPC T6. This basically allows you to use trimmed-down bifurcation adapter. The adapter in question must be trimmed down/cut to fit on the back of the board. Tested with 2x NVME, and 1xNVME and QCNFA765 wireless card. I'll post photos later once I'll disconnect the board again from my setup. BEWARE!!! If you'd plan to use more than one ath11k wireless card, you'd need QRTR patch. Since the SBL enums changed in recent kernel 6.18.18+, I am also preparing modified kernel patch (originally for OpenWRT by Hauke Mehrtens and Robert Marko) to allow for more than one ath11k wireless to be installed. Will post later with new patch for it. root@ap-voyager:~# lspci -nn 0000:00:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01) 0000:01:00.0 Network controller [0280]: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] (rev 01) 0001:10:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01) 0001:11:00.0 Non-Volatile memory controller [0108]: Shenzhen Longsys Electronics Co., Ltd. Lexar NM610 PRO NVME SSD (DRAM-less) [1d97:1202] (rev 01) 0002:20:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01) 0002:21:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) 0003:30:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01) 0003:31:00.0 Network controller [0280]: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] (rev 01) 0004:40:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01) 0004:41:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05) root@ap-voyager:~#

thanks, it is settled now, apt-get update behaves normally.

meco any update on this? dual NVME also does not work on non vendor kernels as well as second HDMI port.