All Activity

Wifi enabled kernel 6.6 https://github.com/hqnicolas/ArmBoardBringUp Will do the PR tomorrow

@ebin-devnearly, I do not change the max value of the voltage (only the min and the central value): change opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; to opp-microvolt = <0xdbba0 0xdbba0 0x1312d0> though it could be you could be able to increase the max value, only I don't know if it is safe and how to know if so. Note that in the edited dts (be it via armbian-config or else) you can replace the hex numbers by decimals. Ie you can write: opp-microvolt = <900000 900000 0x1312d0> It is way easier than computing the hex of the initial voltage with 75mV added. @BipBip1981 best is to have a reproducible way to trigger the crash. Then you can tell when the issue is gone. My test case is https://gist.github.com/prahal/316111da0a9b8cc0d0791d26659dc682 If you can run it without a crash with any kernel it is new to me. (I Believe I even got the linux 4.4 helios64 first kernel to crash with this test case). With this patch to increase the min and "central" voltage (I believe requested voltage) by 75mV I cannot get my above test case to crash helios64 (mind there are other helios64 crashers so it best to run the test case in systemd emergency mode, but I managed to run it 100 times in "full" session mode): EDIT: this patch is incomplete: since then I have added opp-00 an opp-01 with the same values as opp-02 (ir 900000 and the appropriate frequencies) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts index 77844650e2fe..34d94e4d6ada 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts @@ -1160,10 +1160,36 @@ &cluster0_opp { /delete-node/ opp06; }; &cluster1_opp { /delete-node/ opp08; + + /delete-node/ opp02; + /delete-node/ opp03; + /delete-node/ opp04; + /delete-node/ opp05; + /delete-node/ opp06; + opp02 { + opp-hz = /bits/ 64 <816000000>; + opp-microvolt = <900000 900000 1250000>; + }; + opp03 { + opp-hz = /bits/ 64 <1008000000>; + opp-microvolt = <950000 950000 1250000>; + }; + opp04 { + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <1025000 1025000 1250000>; + }; + opp05 { + opp-hz = /bits/ 64 <1416000000>; + opp-microvolt = <1100000 1100000 1250000>; + }; + opp06 { + opp-hz = /bits/ 64 <1608000000>; + opp-microvolt = <1175000 1175000 1250000>; + }; }; &cpu_thermal { trips { cpu_warm: cpu_warm { Mind this patch will not apply (the cpu_thermal is from another patch of mine. But it gives you an idea of what you should write. Also, you should account that crashes might be related to the load or the speed between transitions in the load. So a kernel version might help but will merely hide or render a crash less frequent. But it is not even a workaround, merely it makes the crash more or less frequent. It might be there is still a bug in the kernel that only affects helios64, but it is unlikely. I think I always had the helios64 (even on the first boot after I mounted the box) because I have a mdadm raid10 with ext4 setup. The raid10 stress the board (and especially the big cpus). If you could try my stress with your stable kernel that would help decipher if this kernel is really stable with regards to big cpu. Mind that even with this cpu-b 75mV workaround I still get crashes from my board, but not with my test case, and way less often. I don't have a test case or know what triggered these remaining crashes yet. Also, the fact that upping by 75mV workaround crashes when cpufreq switching the big cpus might not fix the root cause. I am not able to analyze the schematic on my own. We would need someone to do so to get a clearer clue as to why this helps and why it could be required. Finally the rk339 is told to be very robust. So it could be it sometimes works with invalid voltages but not all the time.

Hello! I have a Banana-Pi M1 (Allwinner A20 SoC), where the same issue occurred since March 22nd, 2024. I upgraded from 6.1.63-current-sunxi to 6.6.16-current-sunxi at this date. I could observe in the logs how after some booted time the sysstat-collect services started by systemd took 20-40 seconds to complete. Normally it takes <100ms to do so, and after some time the cpu stalls completely, and the system becomes unresponsive if not rebooted. After reboot, everything fime for some hours, then issue occurs again. Switched to armbian edge (6.7.4-sunxi) kernel, issue persisted. Switched to armbian legacy (6.1.77-sunxi) kernel, issue disappeared. I hope the culprit can be found out, i am willing to assist in error reporting, since my system is non-critical. Thanks for the error report, this way i know i am not the only one!

dang ethernet not found, just like it seems to be mentioned here already. any solutions to that?

+1 to opi zero 3 bookworm from link below booting ok on opi zero 2w https://github.com/armbian/community/releases/download/24.5.0-trunk.433/Armbian_community_24.5.0-trunk.433_Orangepizero3_bookworm_current_6.6.28_minimal.img.xz.torrent

So you don't want to remove: armbian-config armbian-firmware armbian-zsh linux-dtb-current-sunxi linux-image-current-sunxi (those last two are your linux kernel and dtb files - which was the reason you couldn't boot previously) So you can see here the upgrade disabled the armbian apt repository. So it can't install the updated armbian packages. So should be: deb http://apt.armbian.com jammy main jammy-utils jammy-desktop (So uncomment and change all references from focal to jammy) That is coming from one of the armbian* files located in /etc. I don't remember which one. If after everything is upgraded, if it still isn't showing the correct value, you can edit. I think this should get updated by the installation of the correct armbian-bsp-* package.

@ezpc98 armbian-config is just automating the setting of the parameters in ArmbianEnv.txt. So after running it, you can see what is set and adjust manually if you prefer.

Hi Nick. I'm on a business trip now, I'll be able to check on Monday. Maybe I'm just not assembling the firmware correctly? I’ll try to compile it again and publish the output of dmesg or whatever you suggest to understand the problem. Thank you very much for your time and help.

Werner Looks like it's just trixie. built an image with Bookworm (bookworm_edge_6.8.7_minimal) and works with no issues so far Bill

Ok, upgraded successfully. I said no to removing obsolete stuff in the end and it seemed to want to delete armbian stuff. I did not freeze the kernel this time one thing is a bit weird Now it says Armbian 23.02.2 Jammy shouldn't the version be 24. something? I am nearly done, let me know if I can safely run apt update/upgrade? I'd really hate to start over. My /etc/apt/sources.list.d/armbian.list file contents - the directory was a bit different Thank you all so far!

windows WSL2 Delete just the h96 max DTS and DTB from patch\kernel\archive\rockchip64-6.6 Drop the new https://github.com/hqnicolas/ArmBoardBringUp and compile again. sudo gpioinfo I'm also using this method to figure out how to enable 1.8v on Pin12 to AP6335 32*4 + 8*3 + 5 = GPIO4 RK_PD5 8*0 = A 8*1 = B 8*2 = C 8*3 = D Also Trying to disable the kernel 6.2 GPIO I can confirm: the enable pin is RK_PB1 from GPIO2 it will enable wifi by 1.8v on Pin12 to AP6335 I have FIxed the problem with this pin in kernel 6.6 the problem is here: GPIO_ACTIVE_LOW sdio_pwrseq: sdio-pwrseq { status = "okay"; compatible = "mmc-pwrseq-simple"; clocks = <&rk809 1>; clock-names = "ext_clock"; pinctrl-names = "default"; pinctrl-0 = <&wifi_enable_h>; reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>; post-power-on-delay-ms = <100>; };

How are you compiling this dts? Is there a shorter way or you are recompiling the whole kernel?

This is not correct. Due to its size, U-Boot must be run from RAM. The RAM must therefore already be initialized before U-Boot can be loaded at all. This is usually done by Trusted Firmware-A (TF-A). U-Boot is only the payload (in TF-A terminology: BL33). You might want to read TF-A's documentation to understand the boot flow, I think here is a good place to start. You're lucky if TF-A is open source for your SoC, but often only a binary BLOOB for BL2 and BL31 is provided by the SoC manufacturers.

After first boot and initial setup and login, I can enable and start the openssh server with no problem. I'm not sure how generating a set of new keys would help. This happens with numerous images. Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_edge_6.8.6_minimal.img Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_vendor_6.1.43_minimal.img Among others. Legacy image with 5.10.160 kernel does not have this problem Regards Bill

Hi, Not change millivolt value because i afraid to do a mistake I just setting differentes values of freq For moment i am at 400-1200Mhz and not lose connection... Can you explain me command to change milivolt setting if i have futur courage or crazy spirit to try this idea? And i have question, i install my 6.6.27 Kernel .deb build my self with official framework, then i reboot and do my pattern 3 times without crash... Today i reboot and lose connection approximately 10min after boot when i set upper than 1400mhz... milivolt value work before reboot why not after, setting not change? Now i do: git clone --depth=1 --branch=main https://github.com/armbian/build ; cd build/ ./compile.sh kernel BOARD=helios64 BRANCH=current dpkg -i *.deb to install Kernel 6.6.28 4 packages reboot and... uptime 18min... not loose connection ! i become crazy !

Do I understand you correctly that you suggest to increase all opp-microvolt values in opp-table-1 by 75 millivolt ? This would i.e. change opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; to opp-microvolt = <0xdbba0 0xdbba0 0x1437c8>; # here are my current values opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xd59f8 0xd59f8 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x124f80 0x124f80 0x1312d0>; }; };

have you tried to run dpkg-reconfigure openssh-server so a fresh bunch of keys is being generated? Seems like for some reason key generation fails on first boot....

Ok that's all clear now, thanks a lot for the answers!

Hi Dave, I don't see any difference between our dts (That deal with hdmi/audio). Maybe the overlay dtbo_a changed something.? If you can extract that. Have you tried your box with different TV/monitors and hdmi cables? Here's my dts. devicetree.dts

Thanks for the pointer, much appreciated. I scrolled through the list (System > Hardware) and there is an overlay module "rockpi4cplus-usb-host". At least the name suggest it is for this board. If I toggle this option and reboot, assume it will switch the port from OTG To host mode.

You would use armbian-config to enable overlays. But in a quick look there is no such overlay in Armbian.

Here is the partial boot log Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. ssh.service: Control process exited, code=exited, status=1/FAILURE ssh.service: Failed with result 'exit-code'. Failed to start ssh.service - OpenBSD Secure Shell server. ssh.service: Scheduled restart job, restart counter is at 1. Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. Not sure what to do as keys have not been generated yet. Thanks, Bill

....Grrrr I reboot... and now i lose network connection random time (approximately 6-10min) after full boot... and i lose access by USB wire to console... return in unstable world... I become CRAZY ! Back to 400-1200Mhz max schedutil, if lose connection... back to 1200 1200 Performance (equal to fix freq 1200)

I have the installed community build 24.5.0-trunk.417 Bookwarm. Radxa official guidance (link) asks to edit /boot/hw_intfc.conf file to change between host & OTG mode. Armbian build does not have hw_intfc.conf file but I believe /boot/ArmbianEnv.txt is Armbian way to manage the config. what is the correct way add "intfc:dtoverlay=rk3399-usb-otg" overlay in ArmbianEnv.txt file?