Werner

logs?

From a quick research it seems mainline driver does not support this. You need to install out of band driver from realtek

https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/#comment-199170

Okay, didn't bother checking beforehand

I think this patch can also be backported to 6.18.y in Armbian if @rpardini didn't plan to do anyway.

https://patchwork.kernel.org/project/linux-rockchip/patch/20251230-arm64-dts-rockchip-rk3588-npu-enablements-v1-1-d38b182a59e3@pardini.net/ fyi

You are community. Contact yourself As there is no maintainer for this board everyone and nobody the same time is responsible for it. If nobody cares, functionality will fall apart over time.

The userspace is behind, that's not an issue. Hardware support is a kernel thing. If its not there an up-to-date userspace like Forky or Sid means nothing.

Alright, partial success rfkill. Hm perhaps wifi trouble?

Alright, found something. @Meestor_X please try this one: https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img.xz

--> (667) DEBUG: Partition table after write_uboot [ /dev/loop0 ] --> (667) COMMAND: sfdisk -l /dev/loop0 The primary GPT table is corrupt, but the backup appears OK, so that will be used. Disk /dev/loop0: 2.37 GiB, 2541748224 bytes, 4964352 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 62C4432A-F158-49BE-8F59-F5A5895C7057 Device Start End Sectors Size Type /dev/loop0p1 8192 1056767 1048576 512M Linux extended boot /dev/loop0p2 1056768 4962303 3905536 1.9G Linux root (ARM-64) This is what the image looks while still on loop dev just before detaching from. But for some reason its messed up right after. Don't know why...yet root@build:~/build/output/images# parted Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img u b p Error: /root/build/output/images/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img: unrecognised disk label Model: (file) Disk /root/build/output/images/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img: 2541748224B Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags:

I usually just re-plug the sdcard back into my laptop, the fs mounts automatically for me. Using Linux though, no clue about MacOS.

Please set verbosity to 7 in armbianenv.txt to get a clue about what happens after "starting kernel..." data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== Interesting. While this isn't an actual issue since the correct dt was loaded nevertheless it seems like BOOT FDT FILE Is set wrong

moved to tvboxes

https://paste.armbian.com/etukovewas

For once as stated don't use Balena. use Armbian imager or usbimager For the other write the image anyway as it is, try to boot and grab serial logs if there is an actual issue or not.

No logs - no issue.

Hm I briefly remember there was an optional overlay to raise voltage to 1.3 volts..but I don't know why it should be now standard. Did not do any investigation though

npu is there in both vendor bsp kernel 6.1.y. There is no node exposed afaik. Everthing beyond like libraries to use npu is userspace and out of scope of Armbian. edge 6.18.y also has reverse-engineered npu support with a driver called Rocket.

Are you sure you don't mean BSP which stands for Board Support Package??

Have you tried to reach out to the manufactur? https://www.mouser.at/datasheet/3/2627/1/MYD-LT527-SX.pdf Website: en.myir.cn Email: sales@myir.cn Tel: +86-755-22984836

Without schematics, deep knowledgde and a lot of time to waste, this task is probably close to impossible. Only chance I see here is for once assuming the vendor is lazy and the implementation is as close to reference design as it can get. And for the other that there is some android device tree which can be reverse-engineered.

That would be a good start indeed.

Didn't warn ffmpeg from a guts feel years ago that they will issue a takedown if no action is taken? So I'm not surprised. Kind of.

I don't have this hardware. However the last merged PR messing with code for this board/SoC was tested by Igor and he stated it boots just fine.