All Activity

hy guys is it possible to boot the odroid c2 from usb? so i can connect a ssd (M.2 SATA) via usb connector and use this. thank you

Hello. Here are in this thread I post Armbian 24.5.0 Bookworm images that should be compatible with Vontar KK MAX. Also added remarks about dualboot for ex. if we want to make untouched Android and at the same time boot only from SD-Card. Also added recommendations for installation on eMMC.

What UART parameters have you set, especially flow control?

Hello, I crash this night (between 3hours uptime and 6hours uptime, i was sleeping) with 6.6.16 and without voltage correction. (red led flashing) (I crash with version "TRANSITION_DELAY 5000" that i copy/paste upper) Do you know which kernel was running when your box crashed? -> 6.6.28 but maybe with your TRANSITION_DELAY 0 version because i copy/paste from forum and then until now i use github version copy/paste upper I install 6.6.28 without voltage correction and look result List of packages i installed: base-files_24.5.0-trunk-12.4+deb12u5-bookworm_arm64__1-bookworm-1armbian1-Ba4f9-U12.4--deb12u5-R55fa.deb armbian-config_24.5.0-trunk_all__1-SA8477-B0293-R448a.deb linux-dtb-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb armbian-plymouth-theme_24.5.0-trunk_all__1-Bfcdb-R448a.deb linux-image-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb armbian-zsh_24.5.0-trunk_all__1-SAbfee-Baafd-R448a.deb linux-u-boot-helios64-current_24.5.0-trunk_arm64__2022.07-Se092-Pe990-H8c72-V65aa-Bf5f6-R448a.deb root@helios64:~/tmp# uname -a Linux helios64 6.6.28-current-rockchip64 #3 SMP PREEMPT Wed Apr 17 09:19:38 UTC 2024 aarch64 GNU/Linux root@helios64:~/tmp# for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done If not crash, i try TRANSITION_DELAY 0 version if not crash TRANSITION_DELAY 0 version, i stay with this setting If crash i try voltage correction Keep in touch

Debian Buster is end of life. There haven't been any armbian updates for a long time. You can ignore the error as there are no updates to get. You really need to upgrade to a supported Debian release.

I am having this problem with apt-get update, please if someone could help me, maybe we have to change the repositories

I wonder if upping the voltage was the correct fix (and if it would always work). From other rk3399 board schematics and TCS4525 datasheet ... it seems Kobol team designed the board for the TCS4525 regulator used before CPU BIG in a lot of designs and replaced the TCS4525 with the SYR837 later on (without taking into account the different recommendations for the SYR837 ... ie VIN with a 22uF instead of 10uF for the TCS4525). All the components around the SYR837 on the helios64 datasheet match the reference design for the TCS4525 (from Torch Chip, datasheet behind Chinese paywalls). I don't know if replacing the VIN capacitor would be enough to get stable big CPUs...

Using overlays on the PI whilst on Armbian should be no different than doing so on RaspiOS. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix If you don't know how to use them I suggest you use google or check the foundation docs.

I could not get simple SPI device to work even on the Orange Pi Debian image. (So am not sure there is any SPI capable system for it yet). I got normal GPIO operations to work and I2C though but no SPI.

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. If your running a "jammy" version of the build, then you get the RasPi utilities like "raspi-config" and "dtoverlay" that might help. 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.

this should take time, how long did it take to complete? Could you paste the last 10 lines of output from the command (or even a single run)? And maybe run the test with "time for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done" to get the time it took at the end (but if it took ages it ran fine, it is not required to run the 100 iterations anew). It might be that the test runs fine on your hardware. That would be interesting. But as I said as it crashed once I doubted it. One option is that in one one the first attempt you tried: and on the second you tried https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a which has a delay between cpub frequency transition of 5 milliseconds while the first has no delay at this point. (again sorry I did not notice the gist github one had this 5msec delay I added to test if a delay would help. To check you can replace: "#define TRANSITION_DELAY 5000" by "#define TRANSITION_DELAY 0" and check if it crashes. Then it will point to an issue with the delay between switching operating points for the big CPU. Do you know which kernel was running when your box crashed? Also, do you know which u-boot you have? (requires serial console output) Mind you don't need to paste cpufrequtils data because the test case bypasses the cpufrequtils settings and manages the chosen frequencies and how to switch them on its own. Note: if you want to quote a text from this forum, select it with your mouse, a popover box will appear above the selection "Quote selection", click on it. You can quote more than one selection to the same post.

SPI tft can be quite an adventure (possibly difficult) to get going, but you can take a look at this project for some hints. https://github.com/notro/fbtft it would also take figuring out how to work SPI on Armbian and Zero 3 not tried that yet.

@Ikesankom hello, no I didn't test it yet. Actually, I have been busy with other issues and totally forgot to test for the upgrade path. If you have a bit of patience I may give it a shot in the next few days, probably tomorrow.

I'm using Gnome build with the new .dts Today I start a new PR to publish all changes (merged 1h ago) oficial images will be updated on next build (24.5.0-trunk.434)

Hello! I have a SPI touchscreen http://www.lcdwiki.com/3.5inch_RPi_Display How I can made work that screen with orange pi zero 3?

As part of our commitment to social responsibility, we've been part of the 1% for the Planet Network since 2022. The environmental partners we support help to better the planet. View the full article

Hello. Were you able to find a solution to the error?

Actually, i did this below and run your command, result at the end. For information, view freq change with htop command but not load up more than few % root@helios64:~/tmp# cat cpufreq-switching-2.c #include <stdio.h> #include <stdint.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <unistd.h> #include <sys/mman.h> #define MAIN_LOOPS (100) #define TRIALS_PER_TOGGLE (10) #define MAX_MEGS (64) #define CPUL 0 #define CPUB 1 #define TRANSITION_DELAY 5000 const char *cpul_freqs[] = { "408000", "600000", "816000", "1008000", "1200000", "1416000" }; const char *cpub_freqs[] = { "408000", "600000", "816000", "1008000", "1200000", "1416000", "1608000", "1800000" }; uint32_t *megs[MAX_MEGS]; int checked_open(char *name) { int fd = open(name, O_RDWR); char err[128]; if (fd < 0) { snprintf(err, 128, "cannot open %s", name); perror(err); exit(1); } return fd; } #define SCALING_PATHL "/sys/devices/system/cpu/cpu0/cpufreq/" #define SCALING_PATHB "/sys/devices/system/cpu/cpu4/cpufreq/" void browse_freq(int *cpul_index, int *cpub_index, int *cpul_step, int *cpub_step) { static int inited = 0; int freql_target_len; int freqb_target_len; int freqfd; int cpul_freqs_count = 0; int cpub_freqs_count = 0; cpul_freqs_count = sizeof(cpul_freqs)/sizeof(cpul_freqs[0]); cpub_freqs_count = sizeof(cpub_freqs)/sizeof(cpub_freqs[0]); if (!inited) { #if CPUL freqfd = checked_open(SCALING_PATHL "scaling_governor"); write(freqfd, "userspace", 9); close(freqfd); #endif #if CPUB freqfd = checked_open(SCALING_PATHB "scaling_governor"); write(freqfd, "userspace", 9); close(freqfd); #endif inited = 1; } if (*cpul_index >= cpul_freqs_count - 1) *cpul_step = -1; if (*cpul_index <= 0) *cpul_step = 1; if (*cpub_index >= cpub_freqs_count - 1) *cpub_step = -1; if (*cpub_index <= 0) *cpub_step = 1; *cpul_index += *cpul_step; *cpub_index += *cpub_step; #if CPUL printf("cpul_freq %s\n", cpul_freqs[*cpul_index]); freql_target_len = strlen(cpul_freqs[*cpul_index]); freqfd = checked_open(SCALING_PATHL "scaling_setspeed"); write(freqfd, cpul_freqs[*cpul_index], freql_target_len); close(freqfd); #endif #if CPUB printf("cpub_freq %s\n", cpub_freqs[*cpub_index]); freqb_target_len = strlen(cpub_freqs[*cpub_index]); freqfd = checked_open(SCALING_PATHB "scaling_setspeed"); write(freqfd, cpub_freqs[*cpub_index], freqb_target_len); close(freqfd); #endif usleep(TRANSITION_DELAY); } void write_test_data(int nmegs, int toggle) { int cpul_index = 0; int cpub_index = 0; int cpul_step = 1; int cpub_step = 1; while (nmegs--) { browse_freq(&cpul_index, &cpub_index, &cpul_step, &cpub_step); } } void check_test_data(int nmegs, int toggle) { int cpul_index = 0; int cpub_index = 0; int cpul_step = 1; int cpub_step = 1; while (nmegs--) { browse_freq(&cpul_index, &cpub_index, &cpul_step, &cpub_step); } } int main(int argc, char **argv) { int nmegs = MAX_MEGS; printf("allocated %dMB\n", nmegs); int nloop, ntoggle, ntrial; printf("test: toggle freq before write\n"); for (nloop = 0; nloop < MAIN_LOOPS; nloop++) { printf("\r%d/%d ", nloop, MAIN_LOOPS); fflush(stdout); write_test_data(nmegs, 1); check_test_data(nmegs, 0); } printf("\n"); printf("test: toggle freq before read\n"); for (nloop = 0; nloop < MAIN_LOOPS; nloop++) { write_test_data(nmegs, 0); for (ntrial=0; ntrial < TRIALS_PER_TOGGLE; ntrial++) { printf("\r%d/%d, %d/%d ", ntrial, TRIALS_PER_TOGGLE, nloop, MAIN_LOOPS); fflush(stdout); check_test_data(nmegs, 1); } } printf("\n"); return 0; } ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# gcc -o cpufreq-switching-2-b cpufreq-switching-2.c ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# uname -a Linux helios64 6.6.16-current-rockchip64 #1 SMP PREEMPT Fri Feb 23 08:25:28 UTC 2024 aarch64 GNU/Linux ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=schedutil ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# uptime 19:39:19 up 5 min, 2 users, load average: 0.27, 0.54, 0.31 ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done

you mean you have no crash running cpufreq-switching-2-b five times with 6.6.16 and 6.6.28? Yes not crash today. I post soon full test pattern and result with 6.6.16 and then 6.6.28 with source of cpufreq-switching-2-b from https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a compil with gcc -o cpufreq-switching-2-b cpufreq-switching-2.c So it crashed with which kernel? Did you rebuild cpufreq-switching-2-b between the test that crashed and the ones that did not? Yes i rebuild because i build in /tmp directory that what a ramdisk... and lost binary with crash Now i store binary on emmc 😉 I do next test with my armbian 24.2.1 build my self with official framework without any another tune then i do exact same with packages kernel armbian 24.5 build my self with official framework upgrade on my 24.2.1

@BipBip1981you mean you have no crash running cpufreq-switching-2-b five times with 6.6.16 and 6.6.28? No that is not what I expected especially since you told me the first time it crashed and rebooted? So it crashed with which kernel? Did you rebuild cpufreq-switching-2-b between the test that crashed and the ones that did not? You can run the test in a loop 100 times with: for i in $(seq 1 100); do ./cpufreqswitching/cpufreq-switching-2-b; done With only one opp not upped 75mV I have seen tests crash only after 80 runs but without any changes, it seems unlikely. Could you paste the 10 last lines from a cpufreq-switching-2-b run? I could think that any boards have defective components ... but then why did your board crash once and then no more? By the way, do not compile cpufreq-switching.c, as I told you previously it was not the correct code for the test case. Has no use for the issue at stake. It was a first attempt because Kobol team told the crash could be due to too fast frequency switching, so I tried the extremes only. But it turns out these are the most stable and likely the only ones that survive without upping the opp voltage by 75 mV. Yes, because it set the governor to userspace to be able to force switch the frequency via code. After the run, it does not restore the cpufreq-utils governor (/etc/default/cpufrequtils) "systemctl restart cpufrequtils.service" should restore it for you. You mean cpufreq-switching-2-b that output thousands of lines for each run, built with "gcc -o cpufreq-switching-2-b cpufreq-switching-2.c", from: and https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a (note there is a small diff between the two, the "usleep(50);" which should not matter).

Resolved it

Good afternoon @jock, were you able to test the update? Thank you!

Hello. I'm trying to disable Network-Manager to only use isc-dhcp-client and control network settings via /etc/network/interfaces But whenever I disable or delete Network-Manger and install isc-dhcp-client. After restarting the device it loses communication with the network. Follow the data: Device: nanopi core Armbian Bookworm Kernel 6.6.28 How I have done the procedure: apt purge network-manager apt install isc-dhcp-client echo "extraargs=net.ifnames=0" >> /boot/armbianEnv.txt cat << EOF > /etc/network/interfaces auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp EOF