All Activity

Hello! The problem is the missing driver for the rtl8723as. Actually, there is a driver floating around, but adapting and keeping it working on every kernel release require a lot of effort. I don't even have a board with such chip, so it is indeed very difficult, but it may become unworthy of the time spent because realtek drivers are very messy. You could find the source code and compile it yourself, or perhaps desoldering the wifi module and change the chip with another one is easier! It would be even easier to attach an USB wifi device. BTW, in the forum thread there is a success story with rlt8723as driver, you may want to search with forum tools or google.

What other images were you trying Bahtiyar ? I'm intending to use the banana Pi for a 3d printer and EMMC booting is the last thing holding me back.

It is not only about setting default cpufreq governors - there are also other settings essential for the network performance (see here). And for Helios64 it is essential to set the irq smp_affinity: for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done If armbian-hardware-optimization is disabled or has vanished at least the irq smp_affinity should be set for sata (ahci) and for the 2.5G LAN interface (xhci) (i.e. in /etc/rc.local)

Thanks @royk From the archive link I tried with Armbian_24.2.1_Orangepi5_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img : Hit the same package unmet dependency issue. With Armbian_24.2.4_Orangepi5_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop.img I could follow all steps successfully but just always black screen with DRM prime direct to plane, even h264.

@voapilro thanks, I'd do some tests when I've some time, possibly working that into the custom bootloader code so that others can test that as well. I hardcoded 1.5GB as an/the author partly of the h616/h618 dram initialization/detection reported that (some?) 1.5 GB ddr4 dram chips has address wrap around issues https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 I'm not sure if this is after all true. As if that is true, then that writing to and reading the last accessible address e.g. 2GB would actually return a false match, saying that there is memory there when there is actually none (i.e. writes to somewhere else). my guess would be to patch that custom u-boot loader with this 'version 2' codes and let 'everyone' test it out including those having non 1.5 GB boards. we'd probably need a way to collect some feedback from the 'testers' if after all that 'works'. the notion is that if there is after all no wraparound, the codes can possibly be committed to u-boot mainline, and become codes in the mainline u-boot. That is truly ideal. of course, a catch with this code is that we'd assume the only 'odd' size is only 1.5 GB, it is unknown if there could possibly be some other weird permutations e.g. 2.5 GB, 3.5GB, 1.2GB, 0.9GB etc that may declare 'too little' or 'too much' dram for some such boards. for that i'd think the only 'right' way is to wait till someone release a means to read the dram registers, which stores the actual memory sizes configurations.

yep, something is wrong with the 32GB version... i have tested with a few NVMe's still the same result... I will test this one the non Plus version (Orange Pi 5B 32GB)

Hello all, I have here R29_MXQ_221_V1.0_1008, WiFi is RTL8723AS. I used this image: Armbian_24.2.5_Rk322x-box_jammy_current_6.6.22.img Added line in /boot/armbianEnv.txt >> overlays=led-conf7 as respected @jock advice. Now Armbian boot from uSD, but no WiFi, i have a backup of Android kernel, from where i can extract DTB if needed. What should i do about the Wifi ? I can even try to change the WiFi module with another HW...

Awesome

In PR6507 the use of cpufrequtils was removed and the functionality put into armbian-hardware-optimization This commit removes the remaining now unused installs of the deprecated cpufrequtils package Changes to be committed: modified: config/cli/bullseye/main/packages modified: config/cli/common/main/packages modified: config/cli/jammy/main/packages Description How Has This Been Tested? [x] jammy cli build Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code View the full article

I thought you might be interested in the following PRs: https://github.com/armbian/build/pull/6120 https://github.com/armbian/build/pull/6507 In Armbian 24.02 the default governor was changed to schedutil and recently it was changed back to ondemand. There is a lot of discussion about why in these two PRs.

Hi Igor, great work on this HA supervised image for the Edge2 oowow. I install it and all fine, but no access to the usual http:ip:8123 and when I try to list the services or the actual "gdbus introspect --system --dest io.hass.os --object-path /io/hass/os" error: "The name io.hass.os was not provided by any .service files" If I can update or re-install the HA would be nice to know. System: Khadas Edge2 Pro, Install "Armbian_24.2.2_Khadas-edge2_bookworm_legacy_5.10.160.oowow.img.xz" from ooWOW All working fine, I can connect with SSH as usual, can do updates or install; but nothing else for Home Assistant. Any comment is apreciated, have a good one. Richard.

Thanks. I will look through that. For now I have updated from the beta channel to the latest version 24.5.0 with kernel 6.6.30 and hope that helps in some way.

Guys i have an orange pi zero 3 4GB RAM version, with armbian ubuntu running currently with a static ip, and i have installed a vpn service on it and it works wonderfully, but it barely uses all the cores and the ram, so i was wondering about using some kind of virtual machine service like qemu-kvm, lxd or even docker to run virtual machines inside. I know many would say go for docker, although what i need is something closer to a VM than to a container, because i need these VMs to have their very own static ips connected to the network and isolated from the others yet able to send and receive traffic between them and the network, i have read that this kind of behavior might be problematic with docker and it is easier to do with proper virtual machines, but, i dont know how mature are things under ARM, is qemu-kvm working perfectly as it does under x86? i thought about trying LXD but i dont know how well this would go being a canonical thing and because you dont install the OS but download an image from a repository, one that might not have an ARM build for it. So for what i want to do, having container/VMs with static IPs with all the capabilities of networking, which one would suggest to me? if anyone got more info about whatever you suggest it will be much appreciated.

Please if you could share how did you solve it, i and others would surely appreciate it.

For information purposes, that the 1.3-inch SH1106 OLED connected to I2C on OZPI v3 works very well OLED connected to PIN 3 of SDA and PIN 5 of SCK and in armbian-config in HARDWARE set to [*] i2c3-ph Using tools i2cdetect -y shows that the OLED is at address 0x3c All Python code with the adafruit library works fine

Hi, I am having the same issue and I'm in the same scenario as yourself. I also have 2 OPi 5+ one with 16GB RAM and the other 32GB RAM. The 32GB version crashes as soon as the NVMe usage becomes intense. I have tested with different NVMe drives (both are 2TB size so... Not sure if it isn't some limitation on that side) and if I connect it through USB it works without a glitch. I'm starting to suspect something's badly soldered or installed physically. Did you manage to solve your issue?

Hi, we speak same problem to link below. Read last 2-3 pages . Keep in touch

@ag123 I have been doing a lot of tests using official Orange Pi Zero 3 SDK following instructions here, and I think a got a way to detect the right memory size. I was not able to fix random memory size detection yet, so it would be next. Anyway, what I saw is that current memory size detection is based on top address wap around to base address. It works well for 1GB, 2GB and 4GB, but not for 1.5GB, as it is not even tried by this method. So I tried to write something to 1.5GB memory address and looking around memory to find a match, and I did not find anything. Instead what I got is that address maps to nowhere, because writing something and then reading once an again, what I got was a kind of random values. And based on that I coded a memory size fix. First of all I need a funcion to check top memory: bool mctl_mem_matches_top(ulong offset) { static const unsigned value= 0xaa55aa55; /* Take last usable memory address */ offset -= sizeof(unsigned); dsb(); /* Set zero at last usable memory address */ writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Set other value at last usable memory address */ writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Check if the same value is actually observed when reading back */ return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; } And then just use it to fix memory size: static unsigned long mctl_calc_size(struct dram_para *para) { u8 width = para->bus_full_width ? 4 : 2; unsigned long size; /* 8 banks */ size = (1ULL << (para->cols + para->rows + 3)) * width * para->ranks; /* Fix size if last usable memory address is not valid */ if (!mctl_mem_matches_top(size)) size = (size * 3) / 4; return size; }

Description Various minor fixes to rockchip rk3318/rk322x based tv boxes: usb ports gain resets in uboot and kernel, so hopefully they gains some more compatibility and/or less hangups rk3318-box now uses the ddrbin from vendor; it was accidentally switched to uboot TPL during last uboot update some patches have been removed because useless or because things could merged into board dtbs Except for a change in dwc2.c driver in rockchip 32 bit (that may have an effect on OTG port on ASUS Tinkerboard, which is usually unused due to being the power connector), no other boards are affected by these changes. It looks like that USB resets,at least on rk3318/rk3328, are good for USB gadgets and makes the audio gadget work in both UAC1 and UAC2 modes. During previous tests, without these patches, audio gadget were totally refusing to work. How Has This Been Tested? USB device have been tested on all USB OTG/EHCI or hubbed ports on these systems: [x] Tested current 6.6 kernel on rk322x live system, complied edge 6.8 kernel [x] Tested current 6.6 kernel on rk3318 live system [x] Tested current 6.6 and edge 6.8 kernels on rk3328 live system Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

hi @TRay I'd like to suggest playing with libgpiod to get familiar with gpiod based gpio access https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/ The readme is quite instructive https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README unfortunately, I've not tried out gpiod itself and wouldn't be able to say much more about it. Other than to say that I found the kernel repo for gpiod / libgpiod and think it is possibly a good way to do some gpio A good thing is libgpiod has bindings like c++ and python / rust https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings/python/examples which means that starting to play with them can start with python etc. e.g. to try to blink a led connected on the header. That (blinking a led) is normally the 'hello world' for embedded / bare metal programming. I'm not sure if more elaborate stuff like spi / i2c is achieved through the same means, those (SPI / I2C) would likely need messing with DTS and even deep down into the drivers and even lower to bare metal to interface with H618 *hardware* registers (for SPI / I2C etc) , it can be a pretty high bar to jump depending on how much information is available and can be found, e.g. is the SPI / I2C hardware after all publicly documented?

I am using orange pi pc plus after using armbian system, there is an infinite network with WLAN0 and WLAN1, but at present there is no law to use both networks at the same time and connect different SSIDs. Error: Connection activation failed: (7) Secrets were required, but not provided. pi@orangepipcplus:~$ cat /etc/os-release PRETTY_NAME="Armbian 24.5.0-trunk.512 jammy" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.4 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=jammy ARMBIAN_PRETTY_NAME="Armbian 24.5.0-trunk.512 jammy" pi@orangepipcplus:~$ uname -a Linux orangepipcplus 6.6.29-current-sunxi #1 SMP Sat Apr 27 15:11:44 UTC 2024 armv7l armv7l armv7l GNU/Linux pi@orangepipcplus:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.101/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 4555sec preferred_lft 4555sec inet6 fe80::9f55:6e99:c16e:8c7/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.0.214/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0 valid_lft 604097sec preferred_lft 604097sec inet6 fe80::faea:304c:b4b2:2c53/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: wlan1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff pi@orangepipcplus:~$ nmcli device wifi connect <ssid> password <pwd> ifname wlan1 Error: Connection activation failed: (7) Secrets were required, but not provided.

I have question. OZPI v3 has support for hardware DS18B20 thermal sensor via w1-gpio ? In armbian-config when we got to the “system” section and select “Hardware” is not existing w1-gpio or OZPI v3 has not support for w1-gpio hardware ? Does not work because there is no device tree file (in the /boot/dtb/allwinner/) and we need to create it ??? like for OZPI v2 ?: 1. Create text file "sun50i-h616-w1-gpio.dts" /dts-v1/; / { compatible = "xunlong,orangepi-zero2\0allwinner,sun50i-h616"; fragment@0 { target = <0xffffffff>; __overlay__ { w1_pins { pins = "PC9"; function = "gpio_in"; phandle = <0x01>; }; }; }; fragment@1 { target-path = [2f 00]; __overlay__ { onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; pinctrl-0 = <0x01>; gpios = <0xffffffff 0x02 0x06 0x00>; status = "okay"; }; }; }; __symbols__ { w1_pins = "/fragment@0/__overlay__/w1_pins"; }; __fixups__ { pio = "/fragment@0:target:0\0/fragment@1/__overlay__/onewire@0:gpios:0"; }; __local_fixups__ { fragment@1 { __overlay__ { onewire@0 { pinctrl-0 = <0x00>; }; }; }; }; }; 2. After you need to compile it, with command "dtc -O dtb -o sun50i-h616-w1-gpio.dtbo sun50i-h616-w1-gpio.dts" 3. Copy it too /boot/dtb/allwinner/overlay/

Description Cut and sewing work around mailing list/libreelec patches to include a minimum set of patches that attempt to solve the various issues with HDMI on rockchip64 family. This affects both current kernel 6.6 and edge kernel 6.8. References on the forums: https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-output/ https://forum.armbian.com/topic/37166-hdmi-issues-on-6x-kernel/ One kind guy tested the kernel package on rockpro64 and reported success: https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-output/?do=findComment&comment=189646 Also remove a patch named "rk356x-vop2-support", that was not about vop2 support but rather tweaks the HDMI phy timings and code because it has been already included in this more general clock fixes. Jira reference number AR-2118 How Has This Been Tested? [x] Tested on a live Orange PI 4 LTS system [x] Tested on a rk3328 tv box [x] Tested on rockpro64 by the guy in the description Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

I have a Helios64 that I recently reinstalled/updated to the latest Armbain Jammy image after not updating for quite some time and finding some of the repos to be dead. Without the drives initialized the system seems like it will run for days, but with the drives initialized (ZFS), I will get the below error after a few hours of uptime (~8-10 hours). I have seen some threads saying to set the CPU clock to one speed to fix the issue and some people installing a newer kernel (via beta.armbian.com). If anyone has any thoughts on how I could try and make this more stable I would appreciate it. [477435.475903] rcu: INFO: rcu_preempt self-detected stall on CPU [477435.476481] rcu: 3-....: (90606038 ticks this GP) idle=8c74/1/0x4000000000000000 softirq=715905/93001225 fqs=43038032 [477435.477488] rcu: (t=90606039 jiffies g=2287601 q=1361150 ncpus=6) [477549.183778] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1-.... 3-.... } 65978929 jiffies s: 781 root: 0xa/. [477549.184885] rcu: blocking rcu_node structures (internal RCU debug): [477615.481330] rcu: INFO: rcu_preempt self-detected stall on CPU [477615.481904] rcu: 3-....: (90651041 ticks this GP) idle=8c74/1/0x4000000000000000 softirq=715905/93047138 fqs=43059171 [477615.482913] rcu: (t=90651042 jiffies g=2287601 q=1361150 ncpus=6) [477729.401197] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1-.... 3-.... } 66023985 jiffies s: 781 root: 0xa/. [477729.402304] rcu: blocking rcu_node structures (internal RCU debug): [477795.486758] rcu: INFO: rcu_preempt self-detected stall on CPU [477795.487338] rcu: 3-....: (90696044 ticks this GP) idle=8c74/1/0x4000000000000000 softirq=715905/93092997 fqs=43080230 [477795.488344] rcu: (t=90696045 jiffies g=2287601 q=1361150 ncpus=6) [477909.618629] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1-.... 3-.... } 66069041 jiffies s: 781 root: 0xa/. [477909.619735] rcu: blocking rcu_node structures (internal RCU debug): [477975.492185] rcu: INFO: rcu_preempt self-detected stall on CPU [477975.492764] rcu: 3-....: (90741047 ticks this GP) idle=8c74/1/0x4000000000000000 softirq=715905/93138939 fqs=43101769 [477975.493771] rcu: (t=90741048 jiffies g=2287601 q=1361150 ncpus=6) [478089.836039] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1-.... 3-.... } 66114097 jiffies s: 781 root: 0xa/. [478089.837147] rcu: blocking rcu_node structures (internal RCU debug):

check this post: There is a patch by jock which works well.