All Activity

@ebin-dev Thanks for the explanation (i failed to notice that you were setting io_is_busy to a different value). I know that you are still working to stabilize this board. But at the end of this process, it should be possible to submit a PR to incorporate your settings into the base builds. Thus I'm looking for things that will make that difficult. I just added a comment to PR6507 stating that the way io_is_busy is now set doesn't allow it to be overridden if needed.

@ag123 The value of CONFIG_SYS_SDRAM_BASE for opi-zero3 is 0x40000000 i.e. 1GB of memory, so it makes a big difference in results of memory size detection. By the other hand, CONFIG_SYS_SDRAM_BASE was renamed to CFG_SYS_SDRAM_BASE at some point between u-boot-sunxi and latest u-boot official release, so I updated my patch. Besides I was trying to use Armbian builder to generate an u-boot image to test patch: And after that, I got u-boot-sunxi-with-spl.bin in cache/sources/u-boot-worktree/u-boot/v2024.01 folder. So just adding patch to userpatches/u-boot/u-boot-sunxi folder and repeating build, I would get patched u-boot image. Well, to force rebuild, I had to remove packages in output/debs folder. The problem is that patch does not apply to v2024.01 u-boot release, so I had to create a new one from such release. Those new changes are here, and this is the new patch. This way I got a patched u-boot image I attached here. I replaced u-boot in my board by this patched one, and this is what I got: So, I works in my board. Well, It does not boot because of my u-boot configuration. I was no able to get a working Armbian build for opi-zero3, so I am using the vendor opi-zero3 Debian image. Any help for testing patch in other boards would be welcome, specially with1.5GB ones. u-boot-sunxi-with-spl-armbian-v2024.01-20240506-patch.tgz

@SteeMan I tested the latest changes in armbian-hardware-optimize with linux 6.6.8, 6.6.29 and 6.6.30 on a Helios64. The above cpufreqpolicy does not work if 'io_is_busy' is set to 1 on Helios64 at least if the 2.5G interface is used (transmit queue timeouts). In armbian-hardware-optimize (a-h-o) it is set to 1. It must be set to 0 (kernel default). The optimizations for the 1G interface (eth0/end0) in the armbian script (see below) have the effect that those tasks are not performed in the NIC anymore (hardware) but on the CPUs in software. The effect is a huge additional load on the CPUs. Anyway such settings are not necessary with the new EEVDF scheduler anymore. The reason why I am disabling armbian-hardware-optimize is that I need a stable system and I want to avoid any random and untested changes on my system. echo 8 > /proc/irq/$(awk -F":" "/eth0/ {print \$1}" < /proc/interrupts | sed 's/\ //g')/smp_affinity echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 > /proc/sys/net/core/rps_sock_flow_entries echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

The USB power has been a growing issue with my C2 for years now. To have the board use the SSD through a USB/SATA adapter, I now have to power the adapter (which has a Y cable) from a neighbour board. It used to work long time ago without the other board "help". So there is probably a weakening component on my C2. Right now the voltage drops between the +5V barrel alim centre, and USB connectors' 5V. I see no rationale in this. My C2 is now decommissioned (I bought a OPi 3 LTS instead). So I will try to to solder a wire under the board to have the incoming 5V straight to the USB ports. It should not be worse than the Y USB cable bringing the 5V from the neighbour board.

Hi Igor, I understand, I agree, this forum is for the Armbian, not the board. Thank you again for your time, for what is working now, it is waaaayyy faster than my Pi3b !!! In any case, a big thank you for your time! Richard.

I will look into this when time permits but I don't promise to stick in researching very long. Kernel behind this specific hardware, this image, is developed with a solo purpose - to sell hardware and its dead end. For amateur usage, running desktop and similar toying this is usually enough. Rockchip cares only that hardware features works, everything else is unmaintained. We are looking at possible impossible tasks, weeks of work, which is something I can't afford to do in exchange for compliments. This is not Armbian problem. Try switching to normal mainline kernel (named EDGE, 6.8.y, that should not have those errors and that I know where to look for fixing if warnings will pop up. Also I can predict I will not lost more then few hours).

FYI. This is now included in armbian-hardware-optimization as of the 24.05 release of Armbian. which I no you are disabling. Why are you disabling armbian-hardware-optimization? What is it doing that is conflicting with your settings?

Hi, Thank for your files and informations. To my side i don't use 2.5G interface because i don't have router 2.5G (and i don't do this tune: https://blog.kobol.io/2020/11/13/helios64-2-5g-ethernet-issue/ ). For moment, no problem with armbian-hardware-monitor.service enable, i stay with this setting, if one day armbian version will be change to use your workaround upper, i use it. I keep my 6.6.29 build and i build 6.6.30 for futur Keep in touch

@z28z34man See Werner's post

Hi Igor, if this can help or you might already know this: AppArmor issues: "The solution: If the AppArmor is not enabled on your host, add this to the Linux kernel boot parameters: apparmor=1 security=apparmor and then reboot your operating system." CGroup version: "The solution: In a supervised installation if you have switched to CGroup v2 you will need to revert what you did. Or you can re-run the supervised installer to fix it. Please be sure to reboot the system after the installation is done. You should never see this issue on Home Assistant OS as all versions of the OS ship with a supported CGroup version." If that help you, have a great one! Richard.

TLDR; The dtb contains a 75 mV bump for all fast cores as suggested by @prahal. You can find the opp-table-1 in this thread above (posted April 19). Use device tree compiler 'dtc' to apply your own changes (link). The dtb further contains a fix that enables hs400 speed on emmc also proposed by prahal. There is also a change for providing L2 cache information (this is all explained in this post) - and there is also a note that 6.6.29 is stable with those modifications. However, 6.6.29 and 6.6.30 bugs me with frequent transmit queue timeouts while using the 2.5G interface (NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8584 ms). I could not find any combination of settings to get rid of this. Therefore I switched back to 6.6.8 - it works perfectly fine - absolutely no issues. I am using the following configuration were armbian-hardware-optimize.service is disabled and NAS performance is restored (note that io_is_busy is set to 0): (The transfer rate from Helios64 to a MacBook Pro is 280Mb/s using a 2.5G switch in between and a 2.5G USB-C Dongle (Realtek 8156) attached to the Mac) root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand root@helios64:~# cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. for cpufreqpolicy in 0 4 ; do echo 0 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo 200000 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done 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 10 > /proc/irq/$i/smp_affinity done exit 0 root@helios64:~# systemctl disable armbian-hardware-optimize.service root@helios64:~# reboot If you are happy with 6.6.29 or 6.6.30 go ahead. For your convenience I attach the modified dtbs. rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp

Looking to /boot/dtb-6.6.30-current-sunxi64/allwinner/overlay/ for h616 not exit dtbo sun50i-h616-w1-gpio.dtbo So for this reason not available in armbina-config in HARDWARE setup w1-gpio so we can not at current use 1-Wire sensor to define on which GPIO is connected 1-Wire sensor DS18B20 uses the 1-wire bus so it will be nice to have possibility use 1-Wire sensors with OZPI v3

@cad 435 No you aren't really missing anything. In the stable channel, kernel .debs generally only get pushed out every three months when a new stable release is put out (24.05 will be out the end of this month for example). If you want to get regular updates of kernels you need to switch to the nightly builds repository in armbian-config. Right now there is no in between.

This is hard to say as we are talking about non standard Linux kernel. If HA works, IMO you can safely ignore those problems or: New kernel is being developed for several years and it might already be working for this use case. You can try by switching to it (armbian-config -> system -> alternative kernels -> select EDGE 6.8.something), but I give you no warranty that it will work. You might need to start with a new image. If it works well, report back and we will generate images by using that kernel. I know many things in graphical areas are missing there, but for this uses case we don't need HDMI output anyway ...

Hi Igor, the image: "Armbian_24.2.2_Khadas-edge2_bookworm_vendor_6.1.43-homeassistant_minimal.oowow.img.xz" work and after few mins I have access as regular HA. There are few warnings: Unsupported system - AppArmor issues : System is unsupported because AppArmor is working incorrectly and add-ons are running in an unprotected and insecure way. Unsupported system - CGroup version: System is unsupported because the wrong version of Docker CGroup is in use. Is it something you can fix in the image and I'll wait or I can upgrade and it will be fixed ? You did a great job man! I'll try to fix it for now, again thank you ! Richard.

Is it possible to upgrade? I upgraded the system and the kernel via armbian-config, but now I'm on 6.7.4-edge-meson64... I have no idea how to get to newest "latest release" from within the running system tbh... Is it even possible? sudo apt-get dist-upgrade also did really nothing.... I feel like I'm missing some kind of big point here which just hangs before my face, but I don't see it...

Hi, On post below i report i have a stable helios64 with ebin-dev's file dtb for 6.6.29 with ondemand 408-1800mhz Whereis a post explain how dtb file change for understand how that work? You speak about end of cpufreq, armbian-hardware-optimize.service, irq smp_affinity, xhci and ahci... anyone have enough knowlege to explain this change ? It's specific for helios64 support or that will be include on futur armbian for every boards/versions ?

@Victor Pecherskiy Then it seems like a software problem, unfortunately I don't have a 32GB to test it with. And what if you copy the dtb from Joshua Riek's image to your Armbian installation? This is a difference I found but not sure if it's possible to be the cause: https://github.com/Joshua-Riek/linux-rockchip/commit/fdf8d484eccb0949664b78b16e0a275e75c52e0d

Description Devicetree is already in https://github.com/armbian/linux-rockchip so just a board config is enough How Has This Been Tested? [x] ./compile.sh BOARD=rock-5-itx BRANCH=vendor BUILD_DESKTOP=no BUILD_MINIMAL=no DEB_COMPRESS=xz KERNEL_CONFIGURE=no RELEASE=bookworm KERNEL_GIT=shallow, flashed to emmc and boot 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 [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Its a bug. You need to make sure the wireless country code is set, even when its not being used.

Hi. I installed Armbian on a raspberry pi 5. Everything went smoothly, but straight-away, I see that dmesg is filled with this error: brcmfmac: brcmf_set_channel: set chanspec 0x100c fail, reason -52 I'm noticing some inconsistencies on the network, and I'm not sure if this is behind it. I tried installing the firmware-brcm80211, but it didn't help -- in fact, I think it might have made it worse. I've looked all over, but I cannot see any useful information regarding this. It has no usb devices attached, not using and gpio pins or anything fancy. It is just a node on the network that is presenting information on a television screen in our shop. It looks like the driver is not a good match for the hardware (that's my guess, anyway). In the past, I've seen errors like this fixed with the firmware I mentioned above. No such luck this time. Any way I can fix this? Thanks.

Hi all, I decided today to give an Armbian build a whirl as a virtual machine (guest). In particular, Armbian_24.2.4_Uefi-x86_jammy_current_6.6.21_kde-neon_desktop.img. As is usual with installing a virtual machine, it comes up with a default video resolution of 1024x768; I can usually quickly get it full screen on my system as 1920x1080 by going to the System Settings : Hardware : Display and Monitor : etc. However, here there is no hardware subsection at all, and a search didn't turn up a setting to change the display. Any advice on where to find it? I installed the spice guest driver and related packages on the guest. Thanks!

I have the same thing i am only seeing the first 8 pins. i did the "sudo su -" to change to root then the "echo "BOARD=orangepi5b" | sudo tee /etc/orangepi-release" where you able to figure anything out

Which is kind of odd since both Armbian and Joshua's work are very close kernel-wise.

That board is no longer a valid armbian board. It is EOS status (end of support). So there is no Armbian support and no community support for that board.