All Activity

Oops, I screwed up which Android image works. The X96 image, not x96q will launch uboot during the Phoenixsuit flash, but will not fully complete and will complain it needs secure or something, I'll get logs, the Transpeed atv image will flash and will get stuck not getting past sboot. The images in question: X96_S400_20220610-1210 h313_20230921_atv_Transpeed_2_16_orig I can upload them if it will help.

So, unfortunately all the images that I have tried get stuck in fel mode. I do know the G96 needs secure mode according to debug logs when I was using Phoenixsuit before and is signed in test keys if that helps. The h313_20230921_atv_Transpeed_2_16_orig android image will launch into uboot (I can get into uboot shell via serial) and flash in Phoenixsuit, but will get stuck in sboot upon rebooting and unable to get any farther, so no uboot shell. Armbian-unofficial_25.05.0-trunk_Tanix-tx6s-axp313_bookworm_edge_6.12.11 stuck at fel Armbian-unofficial_25.05.0-trunk_X98h_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_X96q-lpddr3-v1-3_bookworm_edge_6.12.11_server also stuck at fel

hi all, pls, is possible to use armbian ueafi-x86 as host for virtualbox? I expect the ubuntu version?? how to install this from cli? recently it seems something was broken on my win11 (after reinstall of new bag of things) or with virtualbox 7.1xx; these were things that worked for years, even with hyper-v on (wsl2), but now, I am writing from armbian, testing old intel nuc10 system booted from sdcard/usb3 (preparing to test new amd machine too) ... virtualbox is quite crucial for some my yold dev things which I can run only in Win2K or Win7; btw, ms copilot was recently quite nice and understanding very tired guy ... https://copilot.microsoft.com/shares/7NhhL6e4MYhkvJC8Grmih Petr

Probably your issue is the proprietary trust os that is shutting the system down in a sort of suspended state

hi, not sure for the sbc, but on uefi-x86, alsa has hdmi audio, but its not loaded for pulseaudio ... ?? here I managed to load it and unmute SPDIF in alsamixer (I still dont understand how devicetree powered SBCs differ against uefi-x86 system ... excuse me) crucial help from Lyra 🙂 ... unmuting SPDIF did the thing, probably also loading the sink also, ufff https://chatgpt.com/share/68836e5f-9e4c-8000-8874-46ea35a07331

wow, the help from chatgpt is in fact quite good ... I now unmuted that SPDIF in alsamixer and tried also to change the pavucontrol configuration profile for something with digital hdmi (but this is NOT necessary ... its all really in the alsamixer unmuting that primary SPDIF - which is reverted to MM with some changes to pavucontrol profile !!) - pavucontroll still shows "headphones" but the audio goes to the hdmi out playing video ... that manual adding of sink to pa probably helped - internal PCI audio shows as "built in audio analog stereo" and the hdmi tv output shows in pa as "builtin audio" ... uff, that audio channels naming ... excuse me, I am linux newbie in this area completelly, may be it was obvious for some, ... quite mess for me but okay, loading module, unmuting spdif ... will see Petr

Those were the days I remember compiling Linux 0.9 something .... it took a day and often nothing worked LOL. In embedded Linux, compiling kernel is nothing unusual, which is the reason why our build framework is focused into making this job easier. For tacking this parameter, you don't need to recompile everything. DTB can be recompiled on a device following by reboot https://www.google.com/search?q=recompile+device+tree+blob Device tree is just a hardware configuration that is provided to the kernel when it boots. This was the only possible related quick, cheap and easy way that I could come up with. Changing the value should have some effect - like (sometimes/always) not detecting PCI when going with weird numbers. More serious debug require a lot more time carefully checking code changes on areas that might have impact alongside with https://www.google.com/search?q=how+to+debug+pci+bus+on+signal+level Which is of course not cheap nor simple.

hi, I have the hdmi issue in uefi-x86 on intel nuc10 minipc - now testing it from fast sandisk microsd in usb3 reader, thats quite fast (after few issues with overheating and slow verbatim and kingston flash keys) this is armbianmonitor output https://paste.armbian.com/jidekuvaza here I tried to ask machine for possible issues and from some detection, it says that my TV is not reporting in EDID any audio?? in windows it works, so may be its something missing? first try to add some forcing to grub didnt helped ... https://chatgpt.com/share/68836e5f-9e4c-8000-8874-46ea35a07331 **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC256 Analog [ALC256 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [Beyond TV] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 falken@uefi-x86:~$ xrandr --verbose | grep -A20 HDMI subconnector: HDMI supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native link-status: Good supported: Good, Bad CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 CONNECTOR_ID: 99 supported: 99 non-desktop: 0 range: (0, 1) 1920x1200 (0x45) 154.000MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.04KHz v: height 1200 start 1203 end 1209 total 1235 clock 59.95Hz 1920x1080 (0x46) 148.500MHz -HSync -VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz 1920x1080 (0x47) 148.500MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz 1680x1050 (0x48) 119.000MHz +HSync -VSync h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 64.67KHz v: height 1050 start 1053 end 1059 total 1080 clock 59.88Hz -- Clones: HDMI-1 CRTC: 1 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff006318512800000100 141d0103807944780a0dc9a057479827 12484c2108008140a940818081c0a9c0 01010101010108e80030f2705a80b058 8a00b9a84200001e023a801871382d40 582c4500b9a84200001e000000fc0042 65796f6e642054560a202020000000fd 00324b1e503c000a202020202020017d 020367f15261605f6665909f05140413 1221225e625d20320907071517505517 016704033d07c05f7e0183010000e200 cb6e030c002000b84421008001020304 68d85dc40178880702e305e301e20f1b -- subconnector: HDMI supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native link-status: Good supported: Good, Bad CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 CONNECTOR_ID: 112 supported: 112 non-desktop: 0 range: (0, 1) 3840x2160 (0x58) 594.000MHz +HSync +VSync +preferred h: width 3840 start 4016 end 4104 total 4400 skew 0 clock 135.00KHz v: height 2160 start 2168 end 2178 total 2250 clock 60.00Hz 4096x2160 (0x59) 594.000MHz +HSync +VSync h: width 4096 start 4184 end 4272 total 4400 skew 0 clock 135.00KHz v: height 2160 start 2168 end 2178 total 2250 clock 60.00Hz 4096x2160 (0x5a) 594.000MHz +HSync +VSync h: width 4096 start 5064 end 5152 total 5280 skew 0 clock 112.50KHz v: height 2160 start 2168 end 2178 total 2250 clock 50.00Hz 4096x2160 (0x5b) 593.407MHz +HSync +VSync h: width 4096 start 4184 end 4272 total 4400 skew 0 clock 134.87KHz v: height 2160 start 2168 end 2178 total 2250 clock 59.94Hz -- HDMI-1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 5494311 Subpixel: unknown Clones: DP-2 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: HDCP Content Type: HDCP Type0 supported: HDCP Type0, HDCP Type1 Content Protection: Undesired supported: Undesired, Desired, Enabled max bpc: 12 range: (8, 12) content type: No Data supported: No Data, Graphics, Photo, Cinema, Game Colorspace: Default supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater aspect ratio: Automatic

@Igor Thanks for the reply. My last self compiled kernel was probably 25 years ago (with make menu-config etc), so i'm not sure if i went the correct way: * cloned into https://github.com/armbian/build * checked the mentioned patch, bus-scan-delay-ms, although i'm on a rockpi-4a and not rockpro64, and the issue is not in 6.6 but in current (6.12), so i changed the parameter in https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/board-rockpi4-0003-arm64-dts-pcie.patch (not sure if this is the correct place?) * ran ./compile.sh KERNEL_BTF=no BOARD=rockpi-4a BRANCH=current (wanted to make sure and compile the whole kernel, instead of just the dtb) * installed resulting image to another sd and booted == same behaviour with kernel panic. also tried to dpkg -i the dtb deb-file only to the current running minimal armbian where i compiled the kernel with, same issue. * tried the same with BRANCH=edge, same result/issue What i wonder in your suggestion, in the 6.6 patch, the value of ms is the same as in the newer version. Why should this be a possible culprit? Today i'm probably trying to build the 6.6 image and check that against my issue. Thanks for any advise in advance.

Whatever help you can provide know that it is truly appreciated! I will follow your suggestion and try a different kernel and report back my findings, thank you!

I just tested shutting down hostapd and restarting, it works systemctl stop hostapd.service systemctl start hostapd.service system process like hostapd should normally be properly started up and shutdown using systemd, killing the process etc may leave the kernel in inconsistent state. And maybe that's why you observe the issue. this is how I set it up https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 accordingly, hostapd may require the interface to be on a bridge, I'm not sure about this, but that I'm using a (software) bridge so that the wifi interface is on it. > uname -a Linux orangepizero3a3 6.12.35-current-sunxi64 #1 SMP Fri Jun 27 10:11:46 UTC 2025 aarch64 GNU/Linux > nmcli c NAME UUID TYPE DEVICE bridge a6aa1bb8-c47e-400e-8de1-7faf96489c7a bridge br0 lo 084c74b2-0638-48be-b4c9-364f854ecabd loopback lo br-eth 6bab09b0-e16c-438b-a1bf-e0d82ca5141b ethernet end0 > sudo bridge link 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 I put both ethernet and wifi on the bridge, wifi is not managed by network manager, hostapd patch that into the bridge. it is possible to just let hostapd setup the bridge in hostapd.conf, and normally that's all needed. this isn't the earliest armbian I'm running hostapd in, i've done it since linux 6.6.x kernel an earlier release some 1 year back or so, no issues.

Maybe some further notes on w.r.t. running HAOS in a VM: As indicated, the process is described for Intel, see https://www.home-assistant.io/installation/alternative For ARM, people have selected RaspberryPi and then ask why it does not work. That is because RPi uses proprietary bootloader (not U-Boot, nor EFI). You need the haos_generic-aarch64 build/image, see https://github.com/home-assistant/operating-system/releases I do not use qcow2, but just a flat img. That is easy to mount as loop device in case some changes are needed to partitions or so. I extracted the .img.xz file and changed the storage (VirtIO Disk) of my existing HA VM to use the new native HAOS instead of my old Debian+supervised_HA. It started without issues and I get to the webpage from where the rest is a standard 'HA getting started', e.g. restore its backup so all devices stats etc are back again. I know many people ask for VMware or Proxmox (or some for VirtualBox), but Linux has anyway all the low-level stuff build-in and a GUI as well: root@rock5b:~# apt install virt-manager virt-manager is already the newest version (1:5.0.0-5). I have this running on ARM64 since Debian Buster 64-bit beta RPi (and 1st early 64-bit Ubuntu server image for RPi4 and also Opensuse Tumbleweed 64-bit) so the commercial ones I dropped long time ago. Above is latest Trixie. Kernel is Armbian vendor currently, but that is only because I want video HW accel (ffmpeg codecs) to work. Otherwise Armbian edge or current offers better stability IMO. Simple tests show that DRAM speed for RK3588 is same or better as for old Intel Core I7, so with also up to 32GB, is great KVM server and desktop same as that old Intel boxes, but 4 Watt idle instead of 40 Watt or so. 40W means about 40 * 9000 is 360 kWh per year, that is 108 Euros per year for my energy contract (30 cents per kWh).

This is the current normal version output: Linux orangepizero3 5.4.125 #1.0.8 SMP Wed Mar 19 23:35:12 CST 2025 aarch64 aarch64 aarch64 GNU/Linux To investigate this issue, I continued to use Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal.img Then uname -a output: Linux orangepizero3 6.12.30-current-sunxi64 #2 SMP Thu May 22 12:29:54 UTC 2025 aarch64 GNU/Linux

The historical archive of armbian orange pi zero 3 seems to have been lost. I am currently using the 5.4 official image.

anything 'interesting' in dmesg? and what is the Armbian / kernel version? e.g. uname -a btw 'real' armbian is currently at linux version 6.12.x https://www.armbian.com/orange-pi-zero-3/ btw I disabled wpa_supplicant when I run hostapd, I'm not sure if it'd affect anything, normally hostapd should work with wpa_supplicant running should be 'no problem'. wpa_supplicant is 'connecting out', while hostapd is an AP hotspot.

It depends on what kind of- and if- HW I/O is used. USB can be redirected. PCI-E can be re-allocated from host to VM when proper IOMMU (HW) is there, that I only go working for Intel PCs, there is interest in it for ARM64, but so far haven't seen anyone got that working. Other typical SBC HW I/O like SPI, 1-wire, GPIO high-low toggle, etc, can not be virtualized, so not available to a VM. Same for video codecs HW accell blocks. Storage and networking, all things typically relevant for enterprise/servers, is no issue.

Has anyone encountered this problem? I reproduced this problem on the 6.1 kernel image, and finally I returned to the 5.4 historical image, and hostapd ran normally.

I tried the following commands, but none of them worked. Only when I rebooted the device did hostapd start correctly. ip link set wlan0 down ip link set wlan0 up rfkill unblock wifi systemctl stop NetworkManager systemctl stop wpa_supplicant

It doesn't work. The wlan0 status is on. I think it's a kernel driver problem.

Welcome / Witaj! Plenty of options for quick and easy start: https://docs.armbian.com/User-Guide_Armbian-Software/ Those small things can do big things

try ip link set wlan0 up

I hope you have realistic expectations - I can only share tips and ideas - fixing is common problem in best effort way. This is most likely related to PCI driver. Which was done badly, its fragile since the day one. Try alternative kernels - and if you find a stable one, report back to forums. This might help nail down this problem.

Here you should have all the debs, you will have to install them manually. Start with media-buster-legacy-rk3328, and then install manually all the deps https://mega.nz/file/RnBQWbBJ#bpVSDcqjatbpwIlKMRopnzSh01ebOxzbMRh1UJ2zBBE

Every time the device is turned on, I can start hostapd for the first time. When I ctrl-terminate, the next time I start hostapd, I get an error message: Failed to set beacon parameters Interface initialization failed wlan0: interface state UNINITIALIZED->DISABLED wlan0: AP-DISABLED wlan0: Unable to setup interface. wlan0: interface state DISABLED->DISABLED wlan0: AP-DISABLED wlan0: CTRL-EVENT-TERMINATING hostapd_free_hapd_data: Interface wlan0 wasn't started nl80211: deinit ifname=wlan0 disabled_11b_rates=0

I have seen other threads where they recompile mesa to get an updated so module for X11, related to LCD panels and DRM. I haven't had time for that yet.