All Activity

Dear All, I get frequent and random disconnection from orangepizero3 onboard wifi with armibian community (self-built) both trunk and 24.02 current kernel, 6.6.26 and 6.6.28 message is always [21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [[21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it Full logs available at armbianmonitor -u Any help/hint/solution deeply appreciated

can't confirm: # cat /var/log/syslog | grep mdadm #

i'm using RFkill command $ rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked i'm switching DTB on this board to test, and I think the problem was on the new DTS file that dont work. rk3566-firefly-roc-pc.dtb rk3566-h96-tvbox.dtb rk3566-h96-tvbox.dts rk3566-firefly-roc-pc.dts

Glad to hear you got it working. I've gone through the same issues you had in the past when trying upgrades, so the steps were in the back of my mind. It should be fine to now remove the obsolete packages.

ok just an update, I managed to get past that '1.5GB' issue the hack is done in u-boot, but the bad news is that that alone won't fix things: U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) sunxi_board_init DRAM:sunxi_dram_initdetected memsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 58 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@5200000: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3259 bytes read in 4 ms (794.9 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 205 bytes read in 4 ms (49.8 KiB/s) 32823 bytes read in 8 ms (3.9 MiB/s) Working FDT set to 4fa00000 4203 bytes read in 7 ms (585.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 10936176 bytes read in 457 ms (22.8 MiB/s) 23570440 bytes read in 982 ms (22.9 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41910000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 10936112 Bytes = 10.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 49592000, end 49ffff30 ... OK Loading Device Tree to 0000000049521000, end 0000000049591fff ... OK Working FDT set to 49521000 Starting kernel ... [ 2.144698] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.153147] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.192185] reboot: Power down This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot. It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration. I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well.

This make Mac Book Air 2010 (Snow leopard) a breeze to Leo Tux ..just the trackpad is crazy but I used a mice - Big thanks to all the Armbian Team! YOUPIE OH!! Cheers SoSie.

It is a twofold problem. First is a base definition compiled with kernel itself, which has to simply put a LUT which ID loads which driver bin file. If it is not there, you will see a dmesg error message. So if this is not recompiled with kernel itself it won't even try to load a bin file nor will it throw any error messages. Can you check if the kernel sees any new hw device IDs?

So it was a success. Version information updated too now But it did want to both uninstall and update armbian-bsp-cli-orangepiplus after updating armbian.list file and running apt update/upgrade Do you think it is safe to autoremove them if the system is up and running? I am so happy I managed to fix my junk from 2015.... It is probably a $30 board from china. But there is just something about making old hardware work for as long as possible. Thank you all!

Seems to be a kernel thing that has changed... Made me curious and I found this: https://forums.raspberrypi.com/viewtopic.php?t=325309 Obv not a solution for you since the tread is about rpi OS (but other hardware outside of rpi is actually mentioned). You might get some good info on how to move forward reading that. I do not know how to do this on armbian. Maybe you can use x11vnc (I have no idea if this exists in the repos) and set the resolution as described here (very old thread): https://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible/40678605#40678605 Or maybe you can do the solution mentioned here, where you get a cheap usb > hdmi adapter for a few $$ that fools the SBC that it has a monitor connected.

nightly kernel? I think you are talking about nightly releases that are not yet stable or tested. Unfortunately I don't have time to test kernels and wait for any bugs.

==> shrink-backup v1.0 <== I have made the decision to not deal with other partitions than boot and root for the 1.0 release. Instead I introduced the --loop function to let the user expand the img file using the [extra space] option and then manually create partitions by running for example: sudo gparted /dev/loop0 in a terminal to edit partitions in a graphical interface using gparted. I want to give the user freedom, but I also have to stay true to my initial plan with this script: a very fast utility to create a bootable img file from the system and subsequently keep it updated. I haven't dropped the idea of at least handling /home completely, but the script goes from "kinda basic functionality" to "advanced script" pretty fast when I start working on the feature. If I do this, I still want the script to be as easy as possible to use, but at the same time give power users the ability to fine tune, ie a lot of work. Features in the release: Introduction of --loop, --fix & -z (zoom speed) Now crosschecks fstab with lsblk for certain operations. Changed MB to MiB etc. Old habits die hard. Will now, if needed, check and/or ask for installing gdisk on debian and arch based systems. GPT partition table now supported Various bug fixes. I hope you find it useful!

Hi @TDCroPower Have you got any issue with systemd-networkd service ? I systematically have a timeout as it seems waiting for all network interface to be ready. $ systemctl status systemd-networkd-wait-online.service × systemd-networkd-wait-online.service - Wait for Network to be Configured Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: disabled) Drop-In: /etc/systemd/system/systemd-networkd-wait-online.service.d └─override.conf Active: failed (Result: exit-code) since Fri 2024-04-19 16:33:57 CEST; 18min ago Docs: man:systemd-networkd-wait-online.service(8) Process: 1188 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE) Main PID: 1188 (code=exited, status=1/FAILURE) CPU: 48ms I use end0 network interface. The other enx646266d00b79 isn't connected I've got a bridge br0 with a virtual tap0 interface (OpenVPN) podman runs a container and enable the interface veth7198de08 and the bridge cni-podman. $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether enslaved configuring 4 enx646266d00b79 ether no-carrier configured 5 br0 bridge routable configured 6 tap0 ether enslaved configuring 7 cni-podman0 bridge routable unmanaged 8 veth7198de08 ether enslaved unmanaged 7 links listed.

By the way, Running Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I notice an error at the beginning of linux boot. "mdadm: initramfs boot message: /scripts/local-bottom/mdadm: rm: not found" Seems an old one as I follow these instructions for Helios4 to solve the issue https://wiki.kobol.io/helios4/mdadm/#fix-mdadm

9 out of 10 times this is better to configure on your dhcp server, usually your router. Set a static ip on your router for the MAC adress on your board. WAY less headaches than starting configuring only the client. :)

The problem here I suspect is the sd-card got tear and wear, hence the capacity might drop, but if you ran a full dd of the entire card, the iso might become bigger than what fits on the sd-card (that now is a tiny bit smaller). It's not unusual that the cells are still readable but not writable, ie you can not modify the data. So when you create the img file, it is a complete one, but your card can no longer fit that img. Let me shamelessly invite you to use my little project: shrink-backup That way your img file becomes the size of the DATA on the device, not the entire thing. Then it will get re-expanded to use the entire sd-card when you boot it the first time after restoration. (if your os is supported, armbian is)

Hi @prahal I've just done a test with your cpufreq-switching-2 program. I'm running Helios64 on Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I've started with LITTLE (CPUL = 1) The program ran the 100 loops without issue. Then I ran with big (CPUB = 1) So far it failed at the 6th loop Before a third run, I tried to change the interrupt allocation on xhci and ahci as you suggested Please note the interrupts may vary after reboot (e.g. ahci was 76-80, after reboot it is 75-79) # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 18: 0 0 0 0 0 0 GICv3 25 Level vgic 20: 0 0 0 0 0 0 GICv3 27 Level kvm guest vtimer 23: 7947 8876 6014 7156 18916 24271 GICv3 30 Level arch_timer 25: 6601 5232 4476 4609 11249 4343 GICv3 113 Level rk_timer 31: 0 0 0 0 0 0 GICv3 37 Level ff6d0000.dma-controller 32: 0 0 0 0 0 0 GICv3 38 Level ff6d0000.dma-controller 33: 0 0 0 0 0 0 GICv3 39 Level ff6e0000.dma-controller 34: 0 0 0 0 0 0 GICv3 40 Level ff6e0000.dma-controller 36: 915 0 0 0 0 0 GICv3 132 Level ttyS2 37: 0 0 0 0 0 0 GICv3 147 Level ff650800.iommu 38: 0 0 0 0 0 0 GICv3 149 Level ff660480.iommu 39: 0 0 0 0 0 0 GICv3 151 Level ff8f3f00.iommu, ff8f0000.vop 40: 0 0 0 0 0 0 GICv3 150 Level ff903f00.iommu, ff900000.vop 41: 0 0 0 0 0 0 GICv3 75 Level ff914000.iommu 42: 0 0 0 0 0 0 GICv3 76 Level ff924000.iommu 43: 0 0 0 0 0 0 GICv3 85 Level ff1d0000.spi 44: 0 0 0 0 0 0 GICv3 84 Level ff1e0000.spi 45: 0 0 0 0 0 0 GICv3 164 Level ff200000.spi 46: 1399 0 0 0 1775 0 GICv3 142 Level xhci-hcd:usb1 47: 30 0 0 0 0 0 GICv3 67 Level ff120000.i2c 48: 0 0 0 0 0 0 GICv3 68 Level ff160000.i2c 49: 5031 0 0 0 0 0 GICv3 89 Level ff3c0000.i2c 50: 540 0 0 0 0 0 GICv3 88 Level ff3d0000.i2c 51: 0 0 0 0 0 0 GICv3 90 Level ff3e0000.i2c 52: 0 0 0 0 0 0 GICv3 129 Level rockchip_thermal 53: 0 0 0 0 0 0 GICv3 152 Edge ff848000.watchdog 54: 0 0 0 0 0 0 GICv3-23 0 Level arm-pmu 55: 0 0 0 0 0 0 GICv3-23 1 Level arm-pmu 56: 0 0 0 0 0 0 rockchip_gpio_irq 9 Edge 2-0020 57: 0 0 0 0 0 0 rockchip_gpio_irq 10 Level rk808 63: 0 0 0 0 0 0 rk808 5 Edge RTC alarm 67: 2 0 0 0 0 0 GICv3 94 Level ff100000.saradc 68: 0 0 0 0 0 0 GICv3 97 Level dw-mci 69: 0 0 0 0 0 0 rockchip_gpio_irq 7 Edge fe320000.mmc cd 70: 0 0 0 0 0 0 GICv3 81 Level pcie-sys 72: 0 0 0 0 0 0 GICv3 83 Level pcie-client 74: 0 0 0 0 0 0 ITS-MSI 0 Edge PCIe PME, aerdrv 75: 0 489 0 0 524 0 ITS-MSI 524288 Edge ahci0 76: 0 0 237 0 0 904 ITS-MSI 524289 Edge ahci1 77: 0 0 0 489 31578 0 ITS-MSI 524290 Edge ahci2 78: 0 0 0 0 249 0 ITS-MSI 524291 Edge ahci3 79: 0 0 0 0 0 248 ITS-MSI 524292 Edge ahci4 83: 14093 0 0 0 0 0 GICv3 43 Level mmc1 84: 0 0 0 0 0 0 rockchip_gpio_irq 5 Edge Power 85: 0 0 0 0 0 0 rockchip_gpio_irq 3 Edge User Button 1 86: 0 0 0 931 0 0 GICv3 44 Level end0 87: 5 0 0 0 0 0 rockchip_gpio_irq 2 Level fsc_interrupt_int_n 88: 0 0 0 0 0 0 GICv3 59 Level rockchip_usb2phy 89: 0 0 0 0 0 0 GICv3 135 Level rockchip_usb2phy_bvalid 90: 0 0 0 0 0 0 GICv3 136 Level rockchip_usb2phy_id 91: 0 0 0 0 0 0 GICv3 60 Level ohci_hcd:usb4 92: 0 0 0 0 0 0 GICv3 58 Level ehci_hcd:usb3 93: 0 0 0 0 0 0 GICv3 137 Level dwc3-otg, xhci-hcd:usb5 94: 0 0 0 0 0 0 GICv3 32 Level rk-crypto 95: 0 0 0 0 0 0 GICv3 146 Level ff650000.video-codec 96: 0 0 0 0 0 0 GICv3 87 Level ff680000.rga 97: 0 0 0 0 0 0 GICv3 145 Level ff650000.video-codec 98: 0 0 0 0 0 0 GICv3 148 Level ff660000.video-codec 99: 0 0 0 0 0 0 rockchip_gpio_irq 2 Edge gpio-charger 100: 0 0 0 0 0 0 rockchip_gpio_irq 27 Edge gpio-charger 101: 2 0 0 0 0 0 GICv3 51 Level panfrost-gpu 102: 0 0 0 0 0 0 GICv3 53 Level panfrost-mmu 103: 0 0 0 0 0 0 GICv3 52 Level panfrost-job IPI0: 1384 1517 1472 1311 4816 7551 Rescheduling interrupts IPI1: 12225 10971 9100 9240 10161 26978 Function call interrupts IPI2: 0 0 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 2213 2003 2357 2402 2137 1671 Timer broadcast interrupts IPI5: 598 601 747 496 1106 784 IRQ work interrupts IPI6: 0 0 0 0 0 0 CPU wake-up interrupts Err: 0 I reallocated the interrupts over the little core. # echo 0 > /proc/irq/46/smp_affinity_list # echo 1 > /proc/irq/75/smp_affinity_list # echo 2 > /proc/irq/76/smp_affinity_list # echo 3 > /proc/irq/77/smp_affinity_list # echo 0 > /proc/irq/78/smp_affinity_list # echo 1 > /proc/irq/79/smp_affinity_list Then I ran the program on the big again (CPUB = 1) And I reach the 25th loop before it failed.

OG Zero has been doing just fine on community support since it stopped having official support, but I think we may be at the point where we will start to see the limitations of community support. If this overheating issue is a quirk specific to Orange Pi Zero, it may never get fixed. Or at least we may have to hope that it gets fixed in the mainline kernel, rather than in the Armbian image. Do you know if it's possible to switch to the nightly kernel as easily as you can switch to the legacy kernel?

1080p on linux? the gpu was working?

OK - I am currently testing your opp-table-1 values (added the missing ones): opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x11edd8 0x11edd8 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x1312d0 0x1312d0 0x1312d0>; }; };

Will attempt tonight.

I got past that DRAM: 0 Bytes it is my own goof when I'm editing the u-boot codes U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 18:04:53 +0800) sunxi_board_init DRAM:sunxi_dram_initmemsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ... the hack seemed to work next I'd need to learn u-boot,

I just enable the enable PIN 12 from HCY6335 I dont know how to select kernel drivers I have tested the new DTB on kernel 6.2 and it doesnt work.

Unfortunately for the second time I found my home server blocked and this time the heat deformed the printed ABS case, I decided that I will put the latest 6.1.53 kernel image starting from scratch with the installation and I will deactivate the kernel updates

Hi, I am glad we have a working image for Rock 3C. I compiled mine and it also works. I have tested HDMI output, network, wifi, and USB. Also, lxd has no issue with the latest kernel. Because it is an unofficial image I found a missing feature to get wifi working as a hotspot. There were a lot of disappeared lines in /etc/hostpad.conf and also there was a message from the console reporting the hostapd is masked in other words is not running during testing maximum wifi speed.

@mongoose I didn't understand the problem, but if you need help here is a tutorial on the orange pi zero. https://hackaday.io/project/181169-orange-pi-zero-native-network-boot/log/196475-step-2-enable-spi-flash-and-and-write-u-boot