All Activity

There are only a few frequencies involved - at least on my board (see the transition tables in my other message in the parallel thread). Upping the voltage by 75mV - as you suggested - helped my board to get rid of remaining few occasional issues during the boot process ! I am measuring the combined power consumption of Helios64 and two 2.5G switches (together 12.66W idle) - it does not seem to be affected at all by that small change. Temperature reported by the Armbian welcome screen is 44 °C (ambient temp 19°C in the basement). Is the remaining crash - once a day on your Helios64 - positively affected by upping the voltage to 1.2V for all states ? If not it may be caused by something else.

You didn't answer my questions? What build did you use and what instructions?

I wanted replace android by armbian on a tv box with S912 to stop use this box as multimedia and have a very small linux server,

What build/download do you have installed? What instructions were you following? No TV box instructions say to use armbian-install.

Hello, I have android tv box with S912. On boot logo was GOOGLE TV and after android app. I put armbian on usb. I boot from usb with armbian by pressing reset button. I backup eMMC with ddbr and save this backup android img file on my computer. I put armbian on my android tv box. No logo, only messages. I don't know how armbian boot usualy, but I think it is same than usb. I think it works well (dual wifi ok, ethernet 100/1000 do not work, bluetooth I don't know). Before add anything, now I want backup eMMC again and save this backup armbian img file on my computer. I need boot from usb with armbian to do ddbr. But it is not possible to do that. Pressing reset button do nothing ! Tuto I read said modify this file /boot/uEnv.txt , maybe I do something bad. Can you help me please ? Sorry for my poor english. Have a good day.

When looking at the cpu frequency transition tables it would appear there are essentially only a few frequencies involved (little cores: 600 <-> 408 <-> 1416 MHz, big cores 816 <-> 1800 MHz) # cat /sys/devices/system/cpu/cpufreq/policy4/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 408000: 0 0 0 0 0 0 0 0 600000: 0 0 0 0 0 0 0 1 816000: 0 0 0 9 12 7 2 262 1008000: 0 0 17 0 1 1 3 1 1200000: 0 0 9 2 0 5 5 4 1416000: 0 0 5 3 6 0 13 12 1608000: 0 0 4 4 2 13 0 12 1800000: 0 0 258 5 4 13 12 0 # cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 408000: 0 2859 4 8 6 1572 600000: 2780 0 5 4 3 104 816000: 14 4 0 7 3 1 1008000: 3 2 5 0 11 14 1200000: 2 2 3 6 0 40 1416000: 1651 28 12 10 30 0

you need to develop your dtbo to support your addon devices. from your description, your device needs a set of SPI pins, and a reset pin. OPI PC plus already provides the pins you want. MOSI SPI0_MOSI / GPIO10 (PIN 19) MISO SPI0_MISO / GPIO9 (PIN 21) SCK SPI0_SCLK / GPIO11 (PIN 23) NSS/Enable SPI0_CE0_N / GPIO8 (PIN 24) then, you need develop a dtbo for your device. 156 &spi0 { 157 status = "okay"; 158 159 YOUR_DEVICE@0 { 160 compatible = "YOUR_DEVICE"; 161 reg = <0>; 162 spi-max-frequency = <50000000>; 163 }; 164 }; if your device use an userspace driver, that not need YOUR_DEVICE@0 node. that all you need to do.

@Trillien thanks, that confirms that I am not alone with a setup that does crash even with 5 milliseconds delay 🙂 If time permits could you try with the TRANSITION_DELAY value increased 10 times in the test case code (to 50millisecs, ie 50000) then 100 times to 500000?

@BipBip1981I agree and I did not plan on doing it on my own. But phone repair shops have skilled technicians who can do it. Still, the need to replace a hardware component is a wild guess. At this point, I was merely saying that I was ready to test a hardware change on my board to find out if the problem was a hardware issue. In the end, I believe that if we better understand what is wrong, be it the hardware, we might even be able to work around such a hardware shortcoming in software. I would not suggest messing with the hardware to test if it works better except if you are ready to lose the board. But mine is so unstable (probably due to my raid10 setup inherited from the helios4) that I could barely use it for years. So it is a matter of either testing if I can get it stable or buying a new NAS and sending this helios64 to the trash. I hope to be able to tell you a good governor/frequency but I need to test more. At least the most reliable frequencies without voltage quirks for the big cpu seemed to be the lowest 408000 and the highest 1800000. So you might want to force the "userspace" governor and "1800000" as a frequency.

I have downloaded a 4k video sample and use the celluloid and mpv media player that came with armbian. it also don't work, keep using 100% CPU i think this is an kernel problem celluloid depends on mpv which depends on ffmpeg Jock made a fix to v4l2 https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ This seems to be discontinued. it was fun while it lasted 🙂 testing now: sudo apt-get install armbian-config sudo armbian-config # SYSTEM # FREEZE sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia sudo apt update sudo apt dist-upgrade sudo apt install mali-bifrost-firmware rockchip-multimedia-config sudo apt install libv4l-rkmpp -y sudo apt install v4l-utils -y sudo apt install ffmpeg -y sudo apt install glmark2-es2-wayland -y Will also try kernel 5.10 https://monka.systemonachip.net/r58-mini/Armbian_23.05.0-trunk_r58-mini_jammy_legacy_5.10.110.AFM.img.xz It has wayland GPU blob + panfork GPU driver + VPU acceleration + box64/86 and wine preïnstalled. from https://monka.systemonachip.net/

I've just tested cpufreq-switching-2-delay5msec in emergency mode. My setup is Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 My first attempt ran for few minutes before freezing and rebooting. Before my second attempt, I blacklist panfrost (not sure there is an impact at all in emergency mode...) $ sudo nano /etc/modprobe.d/blacklist.conf blacklist panfrost I then rebooted and started linux in emergency mode. # lsmod | grep panfrost lsmod didn't catch any panfrost module. Still, cpufreq-switching-2-delay5msec ended with a kernel panic: 10/100 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 [ 51.732314] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ 51.732887] Modules linked in: ip_tables x_tables autofs4 efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid0 multipath linear cdc_ncm cdc_ether usbnet raid1 r8152 realtek rockchipdrm dw_mipi_dsi dw_hdmi analogix_dp fusb302 drm_display_helper cec tcpm drm_dma_helper typec drm_kms_helper dwmac_rk stmmac_platform stmmac drm pcs_xpcs adc_keys [ 51.735962] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.6.8-edge-rockchip64 #1 [ 51.736610] Hardware name: Helios64 (DT) [ 51.736965] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 51.737589] pc : update_blocked_averages+0x278/0x758 [ 51.738051] lr : update_blocked_averages+0x264/0x758 [ 51.738504] sp : ffff800082043e80 [ 51.738806] x29: ffff800082043e80 x28: ffff000005cd9600 x27: 0000000c01b0a9aa [ 51.739456] x26: ffff000005cdbc80 x25: ffff000005cdbc00 x24: 0000000000000000 [ 51.740104] x23: ffff0000f77a0f18 x22: 0000000000000028 x21: 0000000000000000 [ 51.740750] x20: ffff000005cdbd40 x19: ffff0000f77a05c0 x18: 0000000000000000 [ 51.741396] x17: ffff800075e85000 x16: ffff800082040000 x15: 0000000000000000 [ 51.742043] x14: 0000000000000001 x13: 000000000000002a x12: 00000000000e7fe0 [ 51.742689] x11: 0000000000000000 x10: 000000000000002a x9 : ffff000005cdbc80 [ 51.743336] x8 : 0000000000000000 x7 : ffff000005cdbc00 x6 : 0000000000000014 [ 51.743982] x5 : 00000000000003af x4 : 000000000000b6a8 x3 : 0000000000000000 [ 51.744628] x2 : 0000000000000000 x1 : ffff000001d6c400 x0 : ffff0000019c6000 [ 51.745274] Call trace: [ 51.745501] update_blocked_averages+0x278/0x758 [ 51.745924] run_rebalance_domains+0x4c/0x80 [ 51.746313] __do_softirq+0x160/0x3fc [ 51.746649] ____do_softirq+0x10/0x1c [ 51.746985] call_on_irq_stack+0x24/0x4c [ 51.747344] do_softirq_own_stack+0x1c/0x2c [ 51.747727] irq_exit_rcu+0x94/0xd0 [ 51.748051] el1_interrupt+0x38/0x68 [ 51.748382] el1h_64_irq_handler+0x18/0x24 [ 51.748758] el1h_64_irq+0x64/0x68 [ 51.749070] cpuidle_enter_state+0xc0/0x4bc [ 51.749454] cpuidle_enter+0x38/0x50 [ 51.749783] do_idle+0x1fc/0x270 [ 51.750083] cpu_startup_entry+0x34/0x3c [ 51.750444] secondary_start_kernel+0x128/0x148 [ 51.750859] __secondary_switched+0xb8/0xbc [ 51.751249] Code: f940ab20 f9406400 f8766801 b4000101 (f9407020) [ 51.751797] ---[ end trace 0000000000000000 ]--- [ 51.752214] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 51.752826] SMP: stopping secondary CPUs [ 51.753358] Kernel Offset: disabled [ 51.753674] CPU features: 0x1,00000208,3c020000,1000421b [ 51.754152] Memory Limit: none [ 51.754439] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

This board is not a supported board. Moved post to Community Maintained section and added the correct tag for the board.

Hi I'm using an Orange Pi PC Plus with a LoRa HAT (Semtech SX1278) connected via GPIO. The tool which uses this HAT connects directly to the SX1278 chip on the HAT, no protocoll like SPI is needed. I'm using it for several years on RaspberryPi's without problems. But with the latest ARMBIAN Image for the Orange Pi PC Plus Armbian_23.11.1_Orangepipcplus_bookworm_current_6.1.63.img.xz I have issues in this constellation. The tool can not contact the SX1278 via GPIO, said the tool developer. It seems like I have to activate the GPIO pins before. I've tried to find information about that, but without success. So I hope to find here more information and help. I have to use these hardware PINs (these are the PIN descritions on teh Raspberry Pi): MOSI SPI0_MOSI / GPIO10 (PIN 19) MISO SPI0_MISO / GPIO9 (PIN 21) SCK SPI0_SCLK / GPIO11 (PIN 23) NSS/Enable SPI0_CE0_N / GPIO8 (PIN 24) RST GPIO6 (PIN 31) Thanks in advance.

TLDR; yes upping 75mV helps drastically, but is not enough at least for all frequencies. Indeed, before upping by 75mV I could not boot most of the time (only "emergency" mode boot was reliable, ie no raid10 and services off). But it seems 75mV is not enough to compensate for the issue at stake all the time. The thing is I don't know what the root issue upping 75mV workaround is. Could be 100mV is enough, but this is a value based on testing, not a theory that requires 75mV (could be the proper value is upper or could be upping the voltage only helps to cope with voltage drops, making them less frequently drop below a certain value where cpub crashes). The datasheet for the cpub regulator requires a bigger capacitor on voltage input than the helios64 one. But the weird thing is most rk3399 boards also use the same weak below-spec capacitor value at this place. At my level (without understanding the hardware interactions or barely) the next step would be to test if my test case also crashes these other boxes with the same vin too low capacitor ... if they crash we could guess that the design is bad and without a bigger capacitor the regulator cannot deliver the voltage for cpub reliably. Could be we could workaround this in software, but I am not qualified to tell that, at least at this point (I read about how these components work, but I am not an expert. Mind also I tested the board way less for the time to come as now that it is quite reliable I started using it again (been down for months, then I extracted the motherboard to test with the less complex setup possible, in emergency mode). NB: upping the voltage makes the CPU hotter, you might want to check the temperature values (with "sensors"). Mine were fine, way below the throttling temp of 80°C for the rk3399. Even with all opp3 and above at 1.2V. The issue seems mostly of keeping the power consumption low. But I wonder if it has a noticeable effect on helios64 power consumption.

for VAAPI we need https://github.com/rockchip-linux/mpp Also testing Wine on linux aarch64 https://github.com/neofeo/BOX86-BOX64-WINEx86-TUTORIAL https://archlinuxarm.org/packages/aarch64/vulkan-panfrost https://www.cnx-software.com/2023/07/21/arm-panfrost-is-now-the-gpu-driver-for-the-linux-community/

Testing this lineage on RK3566 h96 max No VAAPI No youtube

If the image would have been made by us its download would be either from armbian.com or https://github.com/armbian/community/ or https://github.com/armbian/os and not from some random baidu/google drive.

the question concerns the Armbian system. I don't know who made this image. Maybe one of you? I don't know.

I suggest to ask at the place where you got the image from. There no way we could tell in which way the source has been modified to create it.

Also Runing android APK's on H96 Max with this waydroid image: https://forum.armbian.com/topic/38184-waydroid-for-rk3588-with-armbian-edge-panthor-kernel-68/#comment-188934 No Vaapi on android video players.... Testing: https://mdn.github.io/dom-examples/webgl-examples/tutorial/sample4/ https://mdn.github.io/dom-examples/webgl-examples/tutorial/sample5/ https://mdn.github.io/dom-examples/webgl-examples/tutorial/sample6/ https://mdn.github.io/dom-examples/webgl-examples/tutorial/sample7/ https://mdn.github.io/dom-examples/webgl-examples/tutorial/sample8/ Testing: https://www.wirple.com/bmark/

Hello RuDy_74 I try to do same (armbian on Bqeel K12pro S912) and thank you for yours posts. Some directory or links are deads. Can you resume whitch img and dbt files you used for working fine and install home assistant ? Thank you. PS: sorry for my poor english. brant : Bqeel model : K12 Pro CPU : Amlogic S912 Octa core ARM, Cortex-A53 64 bits – Maximum 2 Ghz GPU : Mali T820MP3 mother board : q201_9377 RAM 2 Go DDR3 ROM : 32 Go eMMC Ethernet Gigabit 100/1000M Wifi : b/g/n/ac – 2,4 & 5 Ghz Bluetooth : 4.1 Micro-SD : maximum 32 Go 2x USB 2.0 ports Android 6.0 (Marshmallow) mother board recto verso (left is left, top is bottom, right is right, bottom is top)

in this case, i think rk3528.dtb was on boot partition. Can you share the: $ lsblk $ df -h $ blkid

Hello I have got the LEMFO RBOX HK1RBOX with rk3528 (https://de.aliexpress.com/item/1005006654505780.html?spm=a2g0o.order_list.order_list_main.32.7cbf5c5fIj4Quv&gatewayAdapt=glo2deu) Is there any img and dtb, that works with this TV-Box. I tried Armbian_24.5.0_rockchip_h28k_jammy_5.10.160_server_2024.04.25.img.gz from ophub with rk3528-hlink-ht2.dtb, unfortunately the LAN did not work, even with all rk3528 dtb's I have tried the image recommended above https://github.com/armbian/community/releases/download/24.5.0-trunk.367/Armbian_community_24.5.0-trunk.367_Hinlink-ht2_bookworm_legacy_5.10.160_minimal.img.xz but I was lost, since the folder structure is different from the ones I am familiar with. I copied the rockchip folder to the boot folder and as well the a armbianEnv.txt adding dtfile=rockchip/rk3528-hlink-ht2.dtb. The original armbianEnv.txt was modified the same way. that did not work. Did you miss any other steps? I would appreciate any hint?