All Activity

@c0rnelius i'd just ask a hint for myself as I'm pretty much noob with armbian development. to make a test of those commits, i'd basically build that image off the current / head in the build repo? https://github.com/armbian/build or that there are some 'staging' images for tests etc? i'm happy with even a kernel image, but I'd need to figure out how to install that and switch to it for the tests. note that i may not personally currently have the 'bandwidth' / time to try things out. and perhaps figure out the defconfig to tweak. I think for the rest, for those who want the 'old' behavior, like my prior response to a new user is to use an 'earlier' release e.g.: there are in fact 'earlier' releases, I'm running an image from this release https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 the cleanup is not necessarily a 'bad thing', just that while this is being done, things will break especially if it is a common defconfig shared among a lot of boards,e.g. opi zero 3 uses its own ethernet chip and wifi chip that could be (is) different from pinephone. i think if those are modules (M) it is still feasible to modprobe them at runtime, I think there is a way to configure it, just forgot how , probably google etc. edit: ok Ii googled it, here is a way to load those modules at boot time. https://www.cyberciti.biz/faq/linux-how-to-load-a-kernel-module-automatically-at-boot-time/ a thing is even for opi zero 3, some of the 'drivers' could even be part of some patches rather than being in the (upstream) kernel itself, that in itself is a complication and worse if that can't even do modules (M) or binding as such and that would likely breaks.

well I "solved" the package conflict but now on boot it shows: Welcome to 22.11.2 with Linux 6.1.115-vendor-rk35xx before it showed: Welcome to Armbian 24.5.1 Jammy everything works though - no pending updates. I guess I will leave it like this. Or any recommendations about getting it up to current version?

@mantouboji My irresponsible job? There was no mystery when the original PR was accepted. It was going to take further effort to get these new defconfigs working for everyone. Do you know what I don't see? I don't see everyone else spamming the web with peoples personal email addresses. Opening and closing PR's with their handle in the subject. Acting like a complete baby because `right at this very moment` it's not perfect for their use case. Give me a break. Your behavior is completely out of line and unacceptable. What was next on ur list of things to do, send me death threats?

I have a couple of cheap Allwinner h313 tv sticks "G96" that I would like to try to port to Armbian. Not exactly sure where to start, but I managed to soft emmc brick one doing so (boots off sd card fine). No compatible firmware is available anywhere, so I rooted it and dumped the emmc firmware, available here: https://archive.org/details/G96_Firmware_Dump . This firmware boots just fine off a sd card. The wifi chip is BCM43340, which has been patched into Armbian before. There are a few more images at the link, let me know what I should do/dump to help.

yaeh, thanks very much .... i just flashed the armbian image to the sdcard copied the base img also on the sd card booted into than dd'ed the copied img to the /dev/mmcblk0 checked the partitions rebooted with removed sdcard and it works !!!

Someone can do random bulk patch to destroy normal applications, as a sufferer and normal application user, I can't report and complain? Are you a Chinese official？ For his irresponsible job, I have to spend a lot of time to find the source code of owfs package and build the development environment to locate the problem. Can we be more serious in doing anything? I'm not the developer of owfs or kernel, only a normal armbian user. He said it is only add a small function to a board, but thousands of lines of configuration changes for the TCP/IP protocol stack were suddenly issued. Is this normal? Is there anyone reviewed carefully? After debug for a long time, I found it is this line failed: pin->file_descriptor = socket(PF_NETLINK, SOCK_RAW , NETLINK_CONNECTOR); It looks his PR destroyed the network stack. I think this is a malicious attack on the armbian project. In the end, it is the reputation of armbian itself that is damaged. I have submitted a PR to rollback to last commit before his PR. Thanks to every serious contributor.

It looks like you have your u-boot loaded to the spi based on what the log shows. So all you should now need to do is install an Armbian image to the SD card, boot into that image and then use armbian-config to copy the image to either eMMC or nvme (you can try both and experiment which you want to go with long term). You also have the option of having /boot on eMMC and the root filesystem on nvme (since the /boot is mostly read only that sometimes is a safer option than relying on being able to boot off of the nvme. There are lots of options available depending on your usage pattern and hardware.

https://docs.armbian.com/Process_CI/

the intention was, not to boot from sdcard .... have read thats not a good solution, sd cards are slow (even if i have an A2 one) and they are not good for constant read and write ... didnt know thats for emmc the same apply for nvme i have read, thats not possible to boot from or its a hassle to get it to work .... but: Scanning bootdev 'nvme#0.blk#1.bootdev': Scanning bootdev 'mmc@fe2c0000.bootdev': looks like he is already try to boot from the emmc and nvme, right ?

@ag123 I'm not really worried about ethernet. Most of these units all use the same thing with the exception of a few special cases. Wireless, sure. I didn't toggle on every USB/SDIO wireless option. That was next on my list of things to do, until today. This is now dropped. My interest in helping is done.

ok, think second way was meant so i formated a sd card with 1 partiton with ext4 putted the images on the root copied the new compiled u-boot-rockchip.bin on the device (sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64) inserted the sd and boot aborting the boot (ctrl+c) sf probe SF: Detected XM25QU128C with page size 256 Bytes, erase size 4 KiB, total 16 MiB => sf update $fileaddr 0 $filesize device 0 offset 0x0, size 0x174800 1384448 bytes written, 141312 bytes skipped in 14.774s, speed 105751 B/s the bytes skipped, is this correct ? removed the sdcard, im getting DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18 ch0 ttot10 ch1 ttot10 ch2 ttot10 ch3 ttot10 ch0 ttot18 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch1 ttot18 channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch2 ttot18 channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch3 ttot18 channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0xff DQS rds:h1,h1 CH0 RX Vref:26.7%, TX Vref:20.8%,22.8% DQ rds:h1 l0 h3 l0 h2 h6 l0 l0, l0 h3 l0 h4 h7 h3 l0 h2 DQS rds:l0,l0 CH1 RX Vref:28.5%, TX Vref:23.8%,23.8% DQ rds:h1 h1 h1 h3 h1 h3 l0 h1, h1 h5 h1 h5 h1 h4 h1 h5 DQS rds:l0,h1 CH2 RX Vref:27.5%, TX Vref:22.8%,22.8% DQ rds:h1 h3 h2 h1 h1 h6 h4 h1, h1 h3 h6 l0 h6 h2 h7 h4 DQS rds:h1,l0 CH3 RX Vref:29.7%, TX Vref:21.8%,21.8% DQ rds:h5 h4 h2 h1 h3 h2 h2 h2, h5 h2 h1 h2 h3 l0 l0 h6 stride=0x2, ddr_config=0x4 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0xa00 0x1400 0x2800 0x0, rank_mask0 0x401000 change to F1: 528MHz ch0 ttot10 ch1 ttot10 ch2 ttot10 ch3 ttot10 change to F2: 1068MHz ch0 ttot14 ch1 ttot14 ch2 ttot14 ch3 ttot14 change to F3: 1560MHz ch0 ttot16 ch1 ttot16 ch2 ttot16 ch3 ttot16 change to F0: 2112MHz ch0 ttot18 ch1 ttot18 ch2 ttot18 ch3 ttot18 out U-Boot SPL 2025.07-g3532f1f5edfc (Jul 24 2025 - 12:04:14 +0200) Trying to boot from SPI ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK NOTICE: BL31: v2.13.0(release):c1ad67a NOTICE: BL31: Built : 11:44:50, Jul 24 2025 U-Boot 2025.07-g3532f1f5edfc (Jul 24 2025 - 12:04:14 +0200) Model: Xunlong Orange Pi 5 Plus SoC: RK3588 DRAM: 8 GiB Core: 356 devices, 31 uclasses, devicetree: separate MMC: mmc@fe2c0000: 1, mmc@fe2e0000: 0 Loading Environment from nowhere... OK In: serial@feb50000 Out: serial@feb50000 Err: serial@feb50000 Model: Xunlong Orange Pi 5 Plus SoC: RK3588 Net: No ethernet found. Hit any key to stop autoboot: 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': Card did not respond to voltage select! : -110 Cannot persist EFI variables without system partition 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Loading Boot0000 'mmc 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'mmc@fe2c0000.bootdev': Card did not respond to voltage select! : -110 Scanning bootdev 'mmc@fe2e0000.bootdev': pcie_dw_rockchip pcie@fe170000: PCIe-6 Link Fail Scanning bootdev 'nvme#0.blk#1.bootdev': pcie_dw_rockchip pcie@fe170000: PCIe-6 Link Fail scanning bus for devices... USB EHCI 1.00 USB OHCI 1.0 USB EHCI 1.00 USB OHCI 1.0 Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fc800000: 1 USB Device(s) found Bus usb@fc840000: 2 USB Device(s) found Bus usb@fc880000: 1 USB Device(s) found Bus usb@fc8c0000: 2 USB Device(s) found Bus usb@fc400000: 3 USB Device(s) found pcie_dw_rockchip pcie@fe170000: PCIe-6 Link Fail Warning: eth_rtl8169 MAC addresses don't match: Address in DT is c0:74:2b:fd:9c:da Address in environment is 1a:21:86:aa:40:10 Warning: eth_rtl8169 MAC addresses don't match: Address in DT is c0:74:2b:fd:9c:db Address in environment is 1a:21:86:aa:40:11 Scanning bootdev 'eth_rtl8169.bootdev': BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 its hanging on trying to boot over network 🙂 there is no bootable device !!! at least it should be does it looks good? whats about the "card didd not respond to voltage select" ?

@c0rnelius lets say that it breaks networking so ethernet and/or wifi is down, we can test that say on OPi Z3. Is there 'images' for it so that we can 'test' it? full images would be huge, but I do not know how to say patch a vmlinuz-6.12.35-current-sunxi64 in boot so that perhaps I can just swap that kernel for the 'test' kernel and test things out, so that those few others who have boards can help test as well. I think some wifi chipsets have 'broken' 'co-exist' issues e.g. that it may not be able to do both wifi and bluetooth at the same time.

I believe this fellas problem is inside CONFIG_INET, but with out information regarding his setup, what the requirements are and error log, how is anyone suppose to help? It is just the endless complaining. The guy is all over the place spamming his complaints. So do me a kindness and don't tell me to cool down. I'm not the one doing that. As for people contributing. How do you think the old defconfigs came into being? People did PR's. That's how it works. I've been at this alone now for what? Several days and have only had one or two people do a PR or tell me what they need. I can't read minds. I can't know every ones setup requirements. All I can do is make a clean working base and we all move forward from there. Apparently that's to much.

Installing rpi-monitor in Armbian for Orange Pi Zero 3 https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5

@c0rnelius lets cool it a little, the defconfigs affects all sunxi64 boards and that they are quite large changes (this should be a pretty large series practially *all* recent sunxi64 boards e.g. orange pis and perhaps a few others. https://github.com/armbian/build/commits/4c0d5af1848e6abcd67b5fc1013e527fd257a894/config/kernel/linux-sunxi64-current.config https://github.com/armbian/build/commits/4c0d5af1848e6abcd67b5fc1013e527fd257a894/config/kernel/linux-sunxi64-edge.config I'd think it helps say to have a (few) dev work the pr as it may become a 'nightmare' if everyone start submitting PR for their 'favourite' defconfigs 😛 but say that those reading the thread are willing to help to test the changes, how do we start? do we need to build the image 'from scratch'? are there 'test' images for this? then that we'd unfortunately have to feed back either 'here' or in the (github) issue tracking it so that the (few) devs working on the pr can 'tweak' the defconfigs or even 'downstream 'configs if need be. I'm not sure if there are per-board defconfigs e.g. for sunxi64 is there a github issue tracking these (works) / (complains) so that it can be addressed (there) ?

this is posted to Gist: https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5 Introduction Rpi-monitor https://github.com/XavierBerger/RPi-Monitor is a very nice app for monitoring sbc (single board computers/ actually bigger computers as well) like RPi on a web. it gives you a quick look at various system metrics cpu load, uptime, temperatures etc and more on a nice web page. and on top, makes nice time series graphs for the same, practically a dashboard. Installing in Armbian 25.8 for Orange Pi Zero 3 Rpi-monitor is normally not found in the common Apt repositories and actually the binary is a little old. I tried installing it based on the 'formal' docs but hit some invalid public keys errors, possibly expired certs. https://xavierberger.github.io/RPi-Monitor-docs/11_installation.html so here is a 'workaround' Deb packages for rpi-monitor you can find the packages in this repository (note that this may not be permanant and may change) https://github.com/XavierBerger/RPi-Monitor-deb use the **rpimonitor_latest.deb** file https://github.com/XavierBerger/RPi-Monitor-deb/tree/develop/packages install rpimonitor_latest.deb in Armbian use apt to install *rpimonitor_latest.deb* as it has varous package dependencies. e.g. download it to a folder and from there run sudo apt install ./rpimonitor_latest.deb the prior step should install rpimonitor, and check that the service is running by going to http://your_sbc_ip_address:8888 checking the setup rpi-monitor is runa as a systemd (unit) service if it is not running you can try systemctl status rpimonitor.service or journalctl -u rpimonitor.service to check what went wrong. to start / stop rpi-monitor it is as per basic systemd services e.g. systemctl start rpimonitor.service temperature 'not displaying' apparently, it is affected by this issue: https://github.com/XavierBerger/RPi-Monitor/issues/374 accordingly the fix/'workaround' is edit /etc/rpimonitor/template/temperature.conf replace #dynamic.1.postprocess=sprintf("%.2f", $1/1000) dynamic.1.postprocess=$1/1000

There has not been a single rollback commit. Instead of making a contribution and helping to move forward, you would instead rather bitch moan. At any point you could have acted like an adult and told me exactly what you needed or at least gave me an error log and it could have been investigated.

thanks again 🙂 the official doc is much better of course 🙂 so i have built the u-boot loader, only warning about op-tee (optional) Image 'simple-bin' is missing optional external blobs but is still functional: tee-os /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os): See the documentation for your board. You may need to build Open Portable Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin Image 'simple-bin-spi' is missing optional external blobs but is still functional: tee-os /binman/simple-bin-spi/fit/images/@tee-SEQ/tee-os (tee-os): See the documentation for your board. You may need to build Open Portable Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin think i dont need this ? but I'm struggeling a little bit with flashing .... I have an u-boot-rockchip.bin u-boot-rockchip-spi.bin the opi5+ has SPI, so the device is mtdblock0 im booted into the device via an armbian image why do i need to write it on the sd card (/dev/mmcblk1) ? where comes the sf command from ? if Im read right, its from the uboot sandbox .... ? So do i have access from the u-boot sandbox to the filesystem ? or does this mean .... i have to copy the u-boot-rockchip-spi.bin to the root of the sd card (can do it on external PC) than boot into the already before existed u-boot stop the boot to get into the sandbox and call the command from there ?

->a bit off topic<- Okay, if you have enough time, you can play around with PXVIRT (formerly the Proxmox port). 🙂 (https://github.com/jiangcuo/pxvirt) It's like Proxmox for ARM64 devices. I've been playing around with an 8 GB Raspberry Pi 4 with a 256 GB USB SSD lying around. In short: I installed a self-made minimal image (RPi4b). Installed PXVIRT (https://docs.pxvirt.lierfang.com/en/installfromdebian.html) Created some LXC containers (e.g., Lyrion Media Server, Heimdall, Pihole, Portainer, etc.) Created a virtual machine (Bookworm with OMV) Created a virtual machine with HAOS / -> bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/vm/pimox-haos-vm.sh)" It's been running perfectly stable for 56 days now. 👍 Okay, it wasn't easy to set up and compile all the software components, but it's running perfectly. I plan to buy an Orange Pi 5 Plus with 32 GB RAM for these tasks next time. Regards, Markus

Colleagues, in order to fully cover the topic and make it easier to diagnose such problems in the future, please tell us what methods and where to look for information/logs about Wayland failures.

The way I do it is to run HA (their HAOS) as a virtual machine. The instructions how to do that are quite clear for Intel, so I did that long time ago on 16GB old Intel Atom server board. Standard 32GB image with partition8 Ext4 data AFAIR. Later on, I created a HA supervised VM for ARM64. I had already several VMs running on a RPI4 for other functions, same libvirtd/QEMU/KVM as on Intel boxes. If you don't know how to get that running, it might be easier to use a docker method, but I consider that as more maintenance (longer term) for myself. I have no real use-case for HA as most I do with own SW. Node-RED, influxDB, Grafana, etc, so currently not running/used. It seems supervised method will loose support sometime, so if I would have to set it up now, I would make a HAOS image running on my ROCK5B (16GB) or NanoPi-R6C (8GB) and import a backup of the database from last year. I can share my serial output of electricity meter now (HW and SW wise) point-to-multipoint, so I will maybe have a look. It is mainly to see how and if metering works for my country/contract out of the box. It is all about the money, we need to pay here for delivering solar energy back to the grid. You need to be a financial expert more or less to get it right. And I am still waiting for cost numbers for energy company, they should have informed me before 2025-07-01, but it seems is it impossible to send an email with 2 or 3 numbers (cents per kWh).

I have tested this on a NanoPi R5C as well as on NanoPC-T6 (non-LTS). For the later I also tested a vender provided Kernel / OS Installation. What happens is that whenever some Power-Saving is requested, the board will seemingly fully power down and is not responsive to anything, at best the reset button will do its work, R5C requires a power-cycle. The last kernel msgs are these (see https://www.kernel.org/doc/Documentation/power/states.txt😞 # echo freeze > /sys/power/state [ 54.373374] PM: suspend entry (s2idle) [ 54.671033] Filesystems sync: 0.297 seconds [ 54.775176] Freezing user space processes [ 54.780065] Freezing user space processes completed (elapsed 0.004 seconds) [ 54.780769] OOM killer disabled. [ 54.781078] Freezing remaining freezable tasks [ 54.782928] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 54.791332] r8169 0002:01:00.0 wan1: Link is Down I am at a loss how to diagnose this further. To me it appears that there is some vital power-source to CPU or RAM switched off.

He broken this function: ` pin->file_descriptor = socket(PF_NETLINK, SOCK_RAW , NETLINK_CONNECTOR); ` and still no fixed, after 3 rollback commits .

Hi every one, Do we have a fix for bluetooth?

Try to experiment with this value: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.6/board-rockpro64-0001-Add-pcie-bus-scan-delay.patch As this is pulled to DT, you only need to recompile DT - on board.