All Activity

Thanks for the initiative with the PR. (Usually we are only asked for money if little help is needed) Here is what happens: The cpufreqpolicy sets a generic value for the sampling_rate of 200000 (this is how often the governor’s worker routine should run, in microseconds). The sampling_rate should be set to a nominal value close to the cpuinfo_transition_latency (49000 nanoseconds for rk3399) such that it is effectively about 1000 times as large. For rk3399 boards the sampling_rate of 40000 is very responsive. In that case no problems occur if io_is_busy is set to 1 ! So you could modify the PR and request that the sampling_rate should be a parameter (per cpu) and be set to the value of the cpuinfo_transition_latency of that cpu (or slightly lower). The fine tuned values for Helios64 are those: for cpufreqpolicy in 0 4 ; do echo 1 > /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 40000 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done

I follow the documentation tutorial step by step, the compilation will sometimes download the kernel and uboot source code, sometimes not download, is there any directive to download all the source code

Hi @ag123 Thank you for the replay but in case the DS18B20 uses a 1-wire bus, libgpiod is used to use the deprecated sysfs interface to GPIO, so it does not apply in this case, but I may be wrong

Any chances you guys could share your images? Been struggling getting a recent image to boot with my 1.5Gb one. only the old official Debian images work. One of the github links from Orange PI provides a bin uboot for the 1.5Gb but I had no luck with that. leeboby/opizero3-uboot-dtb: 保存opizero3 1.5gb和4gb版本的开发板linux6.x系统需要替换的u-boot和dtb文件 (github.com)

Attempting to build this image gives me the following error: [🐳|🔨] Image 'itb' is missing external blobs and is non-functional: opensbi [🐳|🔨] [🐳|🔨] /binman/itb/fit/images/opensbi/opensbi (fw_dynamic.bin): [🐳|🔨] See the documentation for your board. The OpenSBI git repo is at [🐳|🔨] https://github.com/riscv/opensbi.git [🐳|🔨] You may need to build fw_dynamic.bin first and re-build u-boot with [🐳|🔨] OPENSBI=/path/to/fw_dynamic.bin [🐳|🔨] [🐳|🔨] Some images are invalid [🐳|🔨] make: *** [Makefile:1124: .binman_stamp] Error 103 Any help would be appreciated.

@voapilro Thanks To try to get it to boot, try applying the patches https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/patches in particular: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/THS_fix.patch https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/enable_GPU.patch note that these are for mainline u-boot 2024-04 release (tag), the patches are for the same found in Armbian. I really disliked all these 'black magic', but that these are really the 'state-of-the-art'. After I did my initial 1.5GB 'hack' patches, originally I've got that 'gpu overheating' issue. But with that 2 patches, it booted to the prompt ! As for 'vendor' u-boot, I'm suspecting that orange pi customized u-boot to pass some additional variables (possibly hard coded) to boot.scr, boot.cmd. When something fails there, I'd guess it dropped to the u-boot prompt. It'd take figuring out what is the statement that the boot.scr, or boot.cmd aborted and what it needs. When that is figured out, you may also be able to do that same 'black magic', passing the variables boot.scr or boot.cmd is expecting. I kind of disliked these 'black magic', the 'right' way is for these to goto the device tree source or overlays (dts files), so that the relevant board use the correct board dts file instead of hard coding them in u-boot. But it is somewhat the 'state-of-the-art' as well as of current, the catch is mainline u-boot won't boot those custom boot.scr and boot.cmd as those 'special' hard coded variables won't be there. if you clone my repository, I've updated a build guide https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md those steps should compile the mainline u-boot for Orange Pi Zero 3 - note with the '1.5GB hack' my repository is managed using quilt https://wiki.debian.org/UsingQuilt to make edits (note those steps in build.md needs to be done at least once prior this) quilt series quilt push patches/1.5GB_OPZ3_fix.patch vi u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c <- or use any editor you prefer quilt refresh <- note this would update patches/1.5GB_OPZ3_fix.patch quilt push -a <- this applies the remaining of the patches # compile it cd arm-trusted-firmware bash arm-trust-fw-make.sh <- normally only need to be done once, not necessary if that is already built prior cd u-boot bash build.sh # test it if necessary # you can rollback all the patches using # quilt pop -a

does Armbian image use same DDR blobs as Joshua's?

@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

Description Quick fix to hdmi patch due to mainlined hunks. How Has This Been Tested? [x] New fixed patch apply on 6.8.9 edge kernel [x] Compiled rockchip drm code on the fly to check it works Did not check the real functionality, but I hope I did not break anything, the patch is minimal... 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

@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 1 > /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 40000 > /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 Edit: 'sampling_rate' reduced, it was not responsive enough - now 40000 (micro seconds). This value should have about the same value as 'cpuinfo_transition_latency'. io_is_busy can then be set to 1 again. 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 ?