All Activity

I will answer my question very soon, but let me first introduce the candidate that bring us a lot of attention here: aegisub. Most of us think its dev has ended in 2018 and we are stuck to 3.2.2 since. It is not the case there are 2 candidates on the row. I made a big picture and bring the evaluation. I used latest armbian 24.2.1 bookworm arm64 on a sdcard for the test. At the begining it was armbian buster version. I override files and updrade package since. I ensured also to have hardware GL accel with the output on inxi -Gs, we have our Mali friend aboard. Nice! Let's start each aegisub to have the "Big Picture": I ordered from left to right the versions. What I discovered is the copyright date statement back to the past of aegisub 3.2.2 What happen to us when we try yo launch and chose a subtitle/ video file? -aegisub 2.30.2 , open with no popup, we can select a video and play it, sound is ok but we can not move in the video using the sound slider. When we play the video the sound slider does not move..Bad luck! -aegisub 3.2.2 : after cleaning lua scripts /usr/share/aegisub/automation due to unicode incompatibility used in karaskel that make crash aegisub on launch, we enjoy "Wx assert" popups that we can close by unchecking Show this dialog next time and click on Continue button When we open a video then it crash. Oh noo!!! Normally play ends here but many said snap is robust. So I look at it on snapcraft.io and there was a... -aegisub 3.3.3 is provided by procles which is a snap of wanqr latest release. A sudo apt install snapd and then snap install aegisub-procless. makes installation succeed, It installs the ubunto core 22 based ecosystem. Unfortunately, when we trigger it, it did not start. After digging a while , it is due to lua bug in 64 bits arch. I switched to 32bit bit removing snapd:arm64 and installing snap:armhf to force 32bit It went further but I remember we loosed the hardware accel this time . so snapd that could have saved us is not usable. For now, the only fully working aegisub with wx assert annoyances is using debootstrap with schroot in bookworm from jammy. I tried with latest bookworm , it works too.

Good work! Will try to compile it and test it out on my side.

Some settings that were set at build time can't be modified at runtime. This requires a new firmware build, e.g. to set the boot delay to 0, the build configuration has to be set to "CONFIG_BOOTDELAY=0". This is due to the build configuration. The build configuration determines the properties of a binary created from a certain source. These can be detail settings, or even decisive for which hardware it is usable. Finally, U-Boot can be built for all devices from the same source of a given release version. E.g. "make libretech-cc_defconfig" prepares a default configuration for LePotato. You can use "make menuconfig" to fine tune it afterwards. I don't know the details of Armbian's build framework, but I'm sure you can inject a patch that implements your desired change.

Hi, This morning, i do cold boot and crash after few minutes (less than 10min...) Boot is okok but lose ssh connection and to same with usb wire console, i have login and password ask but then i am block... (i can't find if problem hardware... systemd... software...) I use reset bottom and after 15min uptime, i try the same and not lose connection, (i don't understand why not lose connection, i do nothing and Helios64 seem Okok...) i do: (3 times) root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# Not crash/freeze and during this test, i have samba Time Machine backup work and lot of I/O Network and 1GO of data pass from my mac to helios. I don't tune voltage, juste use 6.6.28 Kernel and my standard configuaration.... I run again you program and, i have again Time Machine Backup (samba share in background): | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.28-current-rockchip64 No end-user support: built from trunk System load: 86% Up time: 27 min Local users: 2 Memory usage: 11% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 47% of 14G RX today: 1.5 GiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. helios64@helios64:~$ su - Mot de passe : root@helios64:~# cd /tmp/ root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:34:39 up 28 min, 3 users, load average: 5.87, 4.75, 3.61 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:36:12 up 29 min, 3 users, load average: 4.99, 4.71, 3.70 root@helios64:/tmp# No Problem, To conclude for moment, to my side; 6.6.28 stable but not at cold boot... stable after. Something (hardware or software) when cold boot crash or do bug in linux software... and after reset buttom is Okok... It's crazy i know ! If you want next week, i build a Vanilla armbian from source with official framework and run your cpufreq-switching on it, i think i will have same this day with my standard configuration but maybe not with crash at cold boot If you read my history message about Helios64 since about 3 years... it never stable with standard parameter. I do many tests and to change Kernel and this day the Best Kernel i never use is 6.6.27 and upper because not crash at standard frequency Schedutil Governor The very bad Kernel was 6.X branch, with thing kernel, Helios crash often just when i unlock my raid10 with LUKS cryptosetup And le 5.15.(something)69 or just before was the best stable Kernel with 400-1400Mhz schelutil (i speak about this in very old post) I try again you program, Time Machine Backup is finish... root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:51:25 up 44 min, 3 users, load average: 3.98, 4.58, 4.24 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:53:01 up 46 min, 3 users, load average: 3.03, 4.09, 4.10 root@helios64:/tmp# Not crash, now i go to work office and then pass a weekend with my familly, keep in touch next week Have a good day

@usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram. Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping. All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on. The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline) https://source.denx.de/u-boot/u-boot I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes. I can't figure out why it is not working. All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

@Protx Thank you very much. I am currently compiling other systems, and I will test your solution later. Additionally, I have found that the latest official trunk403 build, as well as the previous trunk250, both exhibit this error. I am testing using an SD card.

Hello everyone Now I have finished compiling armbian once and want to check and change the device tree of uboot, but I don't know where to download it, only see the kernel source code in cache/source, so I want to ask

Ah okay. Trixie is an unsupported userspace anyways. So this might be fixed at some point on the way when it reaches stable.

Yes, mine is 10/100M. I'm using it to watch content on a 1080p TV and works pretty fine. If useful to you, it has an USB 3.0 port, to use an external HDD or probabbly a gygabit LAN to USB dongle...

I tried to dump the full firmware to have a backup but I couldn't do this because its read protection. Apparently I could only extract uboot.img and many other files. There is a workoround by unpacking that file, editing 4 bytes with any HEX editor, repacking and flashing, that allows to fully dump the firmware after tweaking it. I'm not sure of any risk of bricking the device If anything goes wrong. By the momment I cannot unppack the uboot.img file to do the trick. Also I'm looking for some more information about how to use the UART interface with it. I have a UART USB dongle (CP2102 chip) that I believe I can use to connect it. Any information would be appreciated.

@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?

+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?