All Activity

Alright, that took a little bit to find, that chip is small! AXP313A pc21BAA 64N1

Would this be a viable pathway to run Frigate NVR with HA/HAOS?

And here is an armbian-monitor with verbosity set to 7: https://paste.armbian.com/ubuxilosap

Thank you for your reply Igor, I have not changed anything, its using the same power supply it has been using for the past years! I had the SSH terminal open on it and just saw this random output: Message from syslogd@nanopim4v2 at Jul 24 20:22:20 ... kernel:[169328.590321] Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP Message from syslogd@nanopim4v2 at Jul 24 20:22:20 ... kernel:[169328.616489] Code: 54000088 14000011 f9400273 b40001f3 (b9401a63) Not sure if it helps, but afterwards I took a new armbian-monitor capture: https://paste.armbian.com/huzanoyifi

I Know this thread is old but i installer buster on my rk3318 box and the media-buster-legacy-rk3328 package does not exist anymore does anyone have a archive of it

Can you tell me the axp### numbers on the chip? I can’t see it in your pictures. Try these images.. maybe you’ll find one that boots https://github.com/NickAlilovic/build/releases/tag/20250306

Stable images are produced every three months. Development builds are produced at least weekly depending on the support status.

You are most likely fine. But out of curiosity can you run the following: apt list --installed | grep armbian

I need a Linux image for this model that works with Wi-Fi and internal memory. No graphical interface.

Sensor integration: buy a OBD2 to USB adapter and study the OBD2 codes to read the fuel liters/hour, km and km/h. It is very possible there is a python OBD2 library. The SBC should be running continuously in the vehicle, since the car electronic control unit does not have the memory to store the information for you. Python+tkinter/pyqt6+matplotlib is very effective for this kind of apps.

orange pi zero 3 image hasn't received an update since may, maybe that's why

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?

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 !!!

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 ?

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" ?

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

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

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.