xaja34

Hi Guation, thanks for the 1GB RAM fix — it got my Cubie A5E (v1.2, 1GB) booting on Armbian Trixie, kernel 6.18.36-current-sunxi64. I'm seeing very low sysbench cpu scores (single-thread ~56 events/sec, 8-thread ~1246 events/sec) and tracked it down to two things: There's no cpufreq at all in this kernel — no /sys/devices/system/cpu/cpu*/cpufreq directory on any core, nothing in dmesg about cpufreq/opp/nvmem, and clk_summary shows no CPU-core PLL entry whatsoever (only pll-audio1). This matches linux-sunxi.org listing the A523 CPU clock/DVFS driver as still "work in progress" upstream, so it's likely a mainline gap rather than anything board-specific. In the forum thread about your 1GB fix, someone's boot log showed "Failed to set core voltage! Can't set CPU frequency" — which looks like a separate, firmware/U-Boot-level issue tied to the 1GB DRAM voltage parameters, possibly capping the CPU at a fallback clock before Linux even loads.

Thanks IBV, Just got your post. I'll give it a try.

I'm running Armbian off NVMe, and flashed the U-Boot SPI firmware (u-boot-sunxi-with-spl.bin → /dev/mtdblock0) so I no longer need an SD card inserted just to get it booting. That part works great. But now I'd like to be able to pop in an SD card occasionally to try other distros/images without disturbing my NVMe install — and it seems that's not currently possible: with an SD card inserted, the board still boots straight from NVMe and ignores the card entirely. Dug into it a bit over serial console: The default boot_targets is fel nvme0 mmc_auto usb0 pxe dhcp — NVMe is checked before the SD/eMMC. Radxa hit the same issue on the RK3588 boards and fixed it upstream (radxa/u-boot#25, "give SD higher boot priority than NVME"). Would be great to see the same fix applied here. I tried working around it manually (setenv boot_targets 'mmc0 mmc1 nvme0 usb0 pxe dhcp'), which does work for that boot — SD is picked up correctly when present. But saveenv fails with "Unable to use mmc 0:1... Failed (1)", so the change doesn't survive a reboot. Looks like this build uses CONFIG_ENV_IS_IN_FAT targeting mmc 0:1, but the Armbian SD image ships a single ext4 partition there (confirmed with fstype mmc 0:1 → ext4), so the environment can never actually be saved. Is this a known limitation, or is there a recommended way to get persistent SD-over-NVMe priority on this board right now?

Worked for me also. Thanks Samixa

Where can I find the image?

Guation. Would you be willing to share the patches (or Git commits) used to build the 1 GB Cubie A5E images? I'd like to incorporate them into the current Armbian build framework instead of using a prebuilt image.

Guation, the image has no update MTD flash option in armbian-install so I can't boot from a nvme.

To follow up: I have 4 orange pi 3b boards - 3 version 1.1 and one version 2.1. The 6.12.1-edge-rockchip64 kernel didn't work on the 1.1 boards but worked on the 2.1 board Vendoe 6.1.75 worked on both.

Thanks Werner. 6.10.11-edge-rockchip64 worked fine. I guess there is no way to go back to this version. Unfortunately I didn't save an image. Bll

Not recognizing network adapter.

After I shutdown Libre Sweet Potato, the whole network is somehow brought down unless I remove prower from the sbc. Any thoughts. Thanks

I've flashed the Armbian-unofficial_24.8.0 - trunk sweet potato bookwork current 6.6.44 to EMMC and it boots fine to EMMC. However when I insert a SD card, it still boots from EMMC. I've added "boot_targets=mmc1 mmc0" to Armbianext.txt with no luck Can anyone help? Thsnks

Werner Looks like it's just trixie. built an image with Bookworm (bookworm_edge_6.8.7_minimal) and works with no issues so far Bill

After first boot and initial setup and login, I can enable and start the openssh server with no problem. I'm not sure how generating a set of new keys would help. This happens with numerous images. Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_edge_6.8.6_minimal.img Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_vendor_6.1.43_minimal.img Among others. Legacy image with 5.10.160 kernel does not have this problem Regards Bill

Here is the partial boot log Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. ssh.service: Control process exited, code=exited, status=1/FAILURE ssh.service: Failed with result 'exit-code'. Failed to start ssh.service - OpenBSD Secure Shell server. ssh.service: Scheduled restart job, restart counter is at 1. Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. Not sure what to do as keys have not been generated yet. Thanks, Bill

Orange Pi 5 plus. It seems that in the 'edge' kernels, ssh is disabled by default. Since HDMI doesn't function this is a problem. I used the debugging UART and after setup I got the message "ssh.service is disabled" I enabled the service and all is well. Any reason why ssh would be disabled?

When I boot any variant with kernel 6..x.x from SD there is no problem with hdmi. When I flash the same variant to the nvme, it boots fine but there is no hdmi output. The orange pi logo appears for a second, then nothing. I can ssh in and everthing works fine. Any variant with 5.x.x kernel works fine from the nvme, with hdmi output. What I don't understand is that if I have output to hdmi when booting from sd, why not from nvme. What I think is relevent entries in the boot log is below. mmu fe043e00.iommu: Enable stall request timed out, status: 0x00030b Jan 30 09:38:22 orangepi3b kernel: rk_iommu fe043e00.iommu: Enable stall request timed out, status: 0x00001d Jan 30 09:38:22 orangepi3b kernel: rk_iommu fe043e00.iommu: Page fault at 0x00000000ee086d40 of type read Jan 30 09:38:22 orangepi3b kernel: rk_iommu fe043e00.iommu: iova = 0x00000000ee086d40: dte_index: 0x3b8 pte_index: 0x86> Jan 30 09:38:22 orangepi3b kernel: rk_iommu fe043e00.iommu: mmu_dte_addr: 0x00000001f4ffa000 dte@0x00000001f4ffaee0: 0x> Jan 30 09:38:22 orangepi3b kernel: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0 Jan 30 09:38:22 orangepi3b kernel: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0 Jan 30 09:38:22 orangepi3b kernel: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0 Jan 30 09:38:22 orangepi3b kernel: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0 Jan 30 09:38:22 orangepi3b kernel: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at Thanks

Thanks Werner !!

Do the minimal versions of the distributions still support HDMI ? Specifically orange pi 3b kernel 6.7.2 Thanks