Active threads

@usual user thanks for the reply. I found and posted there what I did (edit boot.cmd), but to no success. As you said, it uses the defaults, though this doesn't happen with u-boot on debian. There, I'm able to use setenv and saveenv without issue. I found a guide to build u-boot https://docs.u-boot.org/en/latest/build/gcc.html and https://docs.u-boot.org/en/latest/board/amlogic/libretech-cc.html but I'm not really sure I understand how I could integrate that into an existing armbian image

similar to what @phier asked, I'm trying to change the u-boot environment variable bootdelay . I've tried adding to armbianEnv.txt with no effect (it is still at the default of 2). I then added to boot.cmd and ran This completed and I can see that boot.scr got the line, but still the boot delay is at the default of 2. Any idea what I am missing @lanefu ? I'm on a Le Potato booting from the microsd card

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?

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

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.

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

Please submit a PR, and this can be discussed there.

@darcyg What i meant was that you manually apply the uw5622-fix-adjust-for-rockchip-post-6.1.patch before ./compile command. Then after compilation check that : --> (15) INFO: * patch/misc/wireless-uwe5622/uwe5622-adjust-for-rockchip-post-6.1.patch is included in the log file. BTW: Do not mind the * applying patch/misc/wireless-uwe5622/w-wireless-fix-out-of-tree-build.patch That was a patch I saw was included in the ubuntu rockchip kernel. I do not think that is needed, does not seem to make a difference.

Hi, I have not much time either, but I would like to see an Armbian release for the M1S. I have one M1S unit with me I could use for testing, but I will have to share it with other tasks. Maybe I could help accelerate the process somehow, I just don't know where to start. I have been using Linux on embedded systems for some years, but never went very deep. I have tried the linuxfactory bookworm image and it works, even with the Vu8S 8" display which connects to the MIPI connector. It must be installed to the onboard eMMC. Does someone want to guide me on this? Or maybe supply ready to flash images I could test?

@Dbosco (Assuming you set the settings in Kodi correct: settings->player->videos->render method Allow using DRM PRIME Decoder=enable Allow Hardware Acceleation with DRM PRIME=enable Prime Render Method=Direct to Plane) Perhaps something is wrong with your ffmpeg, mpp or rga. Try to follow the steps on: https://github.com/nyanmisaka/ffmpeg-rockchip/wiki/Compilation After that run the cmake command for kodi again before make and install.

I'm sorry but I don't know the answer, I use my fake Tanix TX3 mini TV box with SOC 905L2-B as a server and I don't know if it's possible to have graphics acceleration with the Linux kernel. This post is related to android factory firmware request. I advise you to write a new one to ask specifically, you could ask in the general chat section of TV boxes forum.

Hello, Is it possible install armbian on allwinner h616 - Cortex A53 - x96 mate ? If yes, where is procedure to do that ? Sorry for my poor english. Thank you for your help.

@A9 they are not errors, just missing firmware files for various wifi devices that you don't really need

moved

No clue as I don't have that box. Search the forums for information. As far as build goes, you should be reading the FAQ posts: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first https://forum.armbian.com/topic/33676-installation-instructions-for-tv-boxes-with-amlogic-cpus

Sorry didn't see your response. 24.2.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop It runs really smoothly as is so I'm considering just leaving it.

Monado, the cross-platform open source XR runtime, has recently received significant updates to align with the features and specifications of OpenXR 1.1, ensuring compatibility and optimal performance for developers and users alike. View the full article

I also am trying to change RasPi device tree, see my post: What I've discovered thus far: Overlays are not enabled for RasPi, if you try to do an "armbian-add-overlay" you get an error. Only way I know at this point for kernel mods that works is to change "/boot/firmware/config.txt" and "/boot/firmware/armbian.txt" . But what you can do there is very limited. Also as an aside the overlays are @ "/boot/firmware/overlays" , and "/boot/dtb/overlays". Root device tree @ "/boot/dtb/broadcom/", but I have not gotten any to load as of yet.

other option would be to enable DT overlays, but at present those are disabled as well.