All Activity

hello, i was trying to set up a 2 pin fan on my orangepi 5b and i connected it to pin 25 and 26 (GND and PWM1). When i first started this task, the output from gpio readall would show me all 26 pins on the board. As i was digging through some forums to try and get the PWM pin to operate as on/off, i came across wiringOP and when i installed it, the output of `gpio readall` changed to only show 8pins. I am unsure of what went wrong and why it only shows 8 pins. I tried removing wiringOP and it still has not made a difference. Thanks

@Ikesankom I did a quick test jiggling with bootloader to try and test multiple cases with both sdcard and emmc. I found a little "bug": there is no "alias" for the mmc devices in the device tree, so sometimes at boot the emmc is mmcblk0 and sdcard il mmcblk2, sometimes they get swapped. Anyway, despite this bug, the installer never broke the existing bootloader, at most it could miss the right device (I should check the logic behind, as it is not so easy guess what is the booting device) if you have both emmc and sdcard plugged. It's not a big deal though: the bootloader has got no real updates in a while since it works fine and the important thing is that the script does not destroy anymore the existing bootloader 😁 Anyway, if the board is remotely installed and controls something important, and you want extra-safety, you can do apt-mark hold linux-u-boot-tinkerboard-current and prevent bootloader upgrades

Result with for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done TRANSITION_DELAY 5000 16h47 6.6.28 NO CRASH ! Tomorrow try with TRANSITION_DELAY 0 Have a good night 9/10, 99/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 root@helios64:~/tmp#

Thank you so much Micsa! This config really "just" worked for me. Now Banana Pi detects either my DS3231 or DS1307 clock.

Can I ask if there is a build for 2gb ram? I'm using Vontar 618 with board vs Transpeed 8k 2gb version so it almost just hangs on the armbian logo. I have tried all versions of armdev build but they don't work

Directly no as it doesn't have any software that would allow this. This way (via SD or eMMC): https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb

@royk thanks for the build, still i didn't test it but i performed some new tests, using the dist from Joshua Riek as Ubuntu is ready, with GPU, and the Kernel is already patched And same problem with Nexus, but i was able to build Omega and is working fine if in System -> Video i select my TV on not the default option (dunno why), after that i can change the resolution to 1080p and everything is working fine, HDR10, x265, x264, 4k.. all good although when i start a video the change of resolution is a bit slow and in the Kodi logs i can see an issue with the EDID: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Error parsing EDID: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] ---------------------------------------------- 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Block 1, CTA-861 Extension Block: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Colorimetry Data Block: Reserved bits MD0-MD3 must be 0. 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] ---------------------------------------------- after these messages in can see in the Kodi log that is able to load all the resolutions profiles Don't know if there is a fix for the EDID After installing Omega it create automatically the GBM profile, using that Kodi works, meanwhile if I'm using yours with the FFMPEG_RKMPP_DEC_OPT="afbc=on" option the video is not showing and Kodi crash cat /usr/local/share/wayland-sessions/kodi-gbm.desktop [Desktop Entry] Name=Kodi on GBM Comment=This session will start Kodi media center Exec=kodi-standalone --windowing=gbm TryExec=kodi-standalone Type=Application Keywords=audio;video;media;center;tv;movies;series;songs;remote; Icon=kodi Also, there was an issue with the python IMP module not found that caused some crashes, and addon probs. finally resolved installing python3-zombie-imp

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?

I'm facing the same situation with a unstable system after trying to update. Having spent a lot of time into troubleshooting and expecting that community support for this device at least will not get better I am also looking for an alternative. Looking for an alternative board is also not that easy because the size (nano-ITX) is not widely spread. Furthermore one requirement for me would be very common hardware/architecture to not depend on special linux distribution, so getting a good mainline support. These days was the release of a new Odroid x86 board "H4" which comes with 4 Sata-Ports. The board physically seems to fit into the Helios64-case but maybe requires some adaption to different hole-positions. Did anybody else already considered that as an option ?

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.