All Activity

Hello, I have the same issue using a Orange Pi 4 (no LTS) : since I have done the update the HDMI doesn't work, but I can reach my OPI 4 using the SSH. Is it a way to fix the issue / activate the HDMI port by any command ? I believe the patch shared is only for the LTS version. Before I updated I had the version : Armbian 23.8.1 Bookworm with Linux 6.1.50-current-rockchip64 After I updated I had the version : Armbian 24.5.1 Bookworm with Linux 6.6.32-current-rockchip64 And the armbianmonitor -u result : https://paste.armbian.com/werugeguso Thanks Viken

Hello, can these exact steps be followed in order to have this working on the Orange Pi 5b?

Description rk-35xx-vendor-6.1 minor touches: - move CONFIG_INPUT_RK805_PWRKEY and CONFIG_PINCTRL_RK805 to modules - move CONFIG_BT to module - add rtw89 8852be/ce wifi support via xunlong/linux-orangepi commit-id 96b2d2827a3f1e4719ebdfcac0b2108e8cbae932 see net: wireless: realtek: Sync rtw89 driver from linux6.2 linux-rockchip-rk3588-edge.config minor touches: - move CONFIG_INPUT_RK805_PWRKEY and CONFIG_PINCTRL_RK805 to modules - move CONFIG_BT to module This enables powerkey functionality for orangepi5-plus OOB Jira reference number AR-2360 How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Built orangepi5-plus images (and ran) vendor/edge RELEASE=trixie Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] My changes generate no new warnings View the full article

Boot process stops after these lines: Cannot lookup file /extlinux/extlinux.conf Cannot lookup file /boot/extlinux/extlinux.conf Cannot lookup file /boot.scr.uimg Cannot lookup file /boot.scr Cannot lookup file /boot/boot.scr.uimg Cannot lookup file efi/boot/bootaa64.efi Card did not respond to voltage select! : -110 No ethernet found. No ethernet found. => It seems that my /boot/boot.scr is silently ignored (at first i was thought it is not even looked for because there is no "Cannot lookup file /boot/boot.scr"). I'll try to enable more logs somehow. File definitely could be loaded by uboot, when I do it manually: => load mmc 1 $loadaddr /boot/boot.scr 5143 bytes read in 14 ms (358.4 KiB/s) => md.b $loadaddr 80 00800800: 27 05 19 56 ad 25 ac 5b 66 65 49 4f 00 00 13 d7 '..V.%.[feIO.... 00800810: 00 00 00 00 00 00 00 00 6d 84 bc 01 05 02 06 00 ........m....... 00800820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00800830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00800840: 00 00 13 cf 00 00 00 00 23 20 44 4f 20 4e 4f 54 ........# DO NOT 00800850: 20 45 44 49 54 20 54 48 49 53 20 46 49 4c 45 0a EDIT THIS FILE. 00800860: 23 0a 23 20 50 6c 65 61 73 65 20 65 64 69 74 20 #.# Please edit 00800870: 2f 62 6f 6f 74 2f 61 72 6d 62 69 61 6e 45 6e 76 /boot/armbianEnv

nanopct6: Kwiboo 24.07 u-boot for edge; bump blobs for all branches nanopct6: Kwiboo 24.07 u-boot for edge; bump blobs for all branches exclusive for edge / Kwiboo: enable UMS / RockUSB and other gadget stuff enable TCP networking features, wget etc enable EFI debugging stuff store environment in SPI uses preboot to flash led briefly this code pattern is becoming copypasta fast and needs refactor before it spreads too much also for all branches (legacy/vendor/edge): BOOTDELAY=1 so we can stop u-boot via UART a bit easier (also for nanopc-cm3588-nas board) can still do it with zero, but it's so much harder; and it's utility outweighs the 1-second delay IMHO nanopct6: updated blobs to DDR v1.16 and BL31 v1.45 View the full article

odroidhc4: bump to u-boot v2024.04; drop most defconfig patches in favor of hooks odroidhc4: bump to u-boot v2024.04; drop most defconfig patches in favor of hooks add pre_config_uboot_target hook for switching BOOTCONFIG across the two targets adapt UBOOT_TARGET_MAP to not call the defconfig Makefile targets directly, instead, just do a variable assignment (ignored by Make) otherwise, when using the defconfig directly in the UBOOT_TARGET_MAP, the post_config_uboot_target .config changes are overwritten when Make is called only patch left is boot usb-nvme-scsi/sata first (still done in meson64.h) remove FIP handling from family file meson-sm1.conf into board file hook where it belongs u-boot: enable more compression methods, EFI debugging, i2c, leds, tcp networking use flashcp for mtd writing Unchanged: confirmed as of v2024.04: using the C4 (not HC4) defconfig is still needed to be able to write to mtd when booted from SD also confirmed: one still needs to erase Petitboot using Petitboot, then boot from SD, to be able to flash mainline u-boot to mtd View the full article

Description Maintenance job. We provide options to build several desktop combinations, but we don't have a mechanism for verifying if those targets still work. I developed a simple action script that cycles all variants that are either supported or community supported. Community supported will only check for deboostrap success. This commit is a result of reading build logs of that Action script. Kde-Neon is in EOS zone as it doesn't build anywhere (atm). AR-2358 How Has This Been Tested? [x] Targets were tested for (x86 qemu which will be further tested on VM once CI extents to this functionality) image compiling. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Description Due to crypto policy update, apt now (since v2.7.13, see the commit) requires repositories to be signed using one of the following public key algorithms: RSA with at least 2048-bit keys Ed25519 Ed448 Affected: Ubuntu Oracular when adding Mesa PPA. More info https://ubuntuhandbook.org/index.php/2024/04/workaround-apt-warning-signature-key-uses-weak-algorithm/ Jira reference number AR-2359 How Has This Been Tested? [x] https://github.com/armbian/os/actions/runs/9434613892 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Hello. I'm building an armbian image and want to add some partitions to the result disk. I use the post_create_partitions hook to do that. The documentation doesn't show how to use it, so I looked at the armbian's sources: https://github.com/armbian/build/blob/99815c0a8880d4e04fc64742412632e1d41c1334/lib/functions/image/partitioning.sh#L206 Here they create a string and pass it to sfdisk. In my hook I do a similar row to add two partitions: echo -ne "label:dos\nsize=1G\nsize=1G\n+\n" | sfdisk -a "${SDCARD}".raw --no-reread || exit_with_error "Partition fail." But building of the image fails with message: No free sectors available. Failed to add #3 partition: No space left on device. How to add partitions?

Yeah cpufrequtils is deprecated. The way to go today seem to use linux-cpupower. No idea though how well this works on SBCs.

Updating some HDMi Audio fix K510 V7, Found this HDMI fix for Roc PC "same board as H96-max" sudo systemctl status ap6335-bluetooth gpioinfo rfkill Full dmesg journalctl -b | grep Bluetooth

@Alex ThreeD actually it is in the wild and it looks to work right to me, also executes boot.scr script. boot.scr is essential to read armbianEnv.txt and apply dtb overlays as well. Did you notice something wrong?

As of the 24.05 release Armbian no longer uses the package cpufrequtils. It now uses that configuration file directly, and replaces the basic functionality that the package cpufrequtils formerly provided. So the Armbian hardware optimization service reads this file and applies the values to the system, and armbian-config is responsible to modify it.

Thank you! Well, it is not obvious who actually made this, in the box there is a reference to "Shenzhen Chensen Technology Co., Ltd" but that seems a led lamp manufacturer, and a phone and mail that look like the importer. I asked an aliexpress seller that is selling these but don't have much hope. In a thread here someone came with a different box having exactly the same chips and said that multiboot worked. To me it is starting to look like a hardware problem, maybe some bad solder ball on the BGA chips, as a last resort I may try a reflow.

Some questions here: Isn't cpurequtils deprecated? So any other edit to other file is just ignored on reboot? Could you suggest the appropriate values to apply for min/max? Just as a test I set it to false again, so not using cpurequtils and armbian-config says I'm between 2000 and 2000 Mhz. So, I suppose I'm using the values I applied before.

On boot the system will apply the values from /etc/default/cpufrequtils to the running system (it is done by the armbian hardware optimization service)

Thank you! Was looking there just now. I already did: echo 1400000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq echo 200000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq that resulted in steakhutzeee@dk:/sys/devices/system/cpu$ grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:155000 /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:userspace powersave conservative ondemand performance schedutil /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory But I see a different value in: steakhutzeee@dk:/sys/devices/system/cpu$ cat /etc/default/cpufrequtils ENABLE=true GOVERNOR=ondemand MAX_SPEED=2000000 MIN_SPEED=2000000 So which values should I set here? And how can I manage the edits I made before? Maybe this is true only when using DBT instead of using CPU under armbian-config? Thank you!

You can manually set this info in /etc/default/cpufrequtils

Hi @jock. Main branch with new uboot 2024.1 is not ready to boot yet, right? (It seems new uboot doesn't even look for /boot/boot.scr) Nice HDMI output in uboot, btw, thanks!

I sent them a message, even sent an email and a whatsapp to the manufacture ( junuo ? hehe) , will see if I get a reply, google sadly doesn't help as seems it's the latest version of the board (v3.0), I really want to make this wifi work 😂 The thing about SBC is that I already have one, the thing is that I spent some good time searching for a chip that would have multiple usb hosts instead of just one, and that's not easy to find, specially not below 50 euros, I came across the rk3228, that somehow is available at those tv boxes :(.

Updating some bluetooth fix K610 V12, doesn't work, but it was there on HCi Line talking.... sudo systemctl status ap6335-bluetooth gpioinfo rfkill Full dmesg journalctl -b | grep Bluetooth

Hi, I'm running OMV on Odroid HC2. I updated to OMV 7.7.1. Armbian to 24.5.1 with Linux kernel 6.6.31-current-odroid-xu4. After reboot the server started to act very slow. I tried to reapply the DBT for HC1/2 via armbian-config but this did not help. armbian-config says I'm on ondemand governor between 200-200 MHz. What could be the issue? Actually my system says I should run dpkg --configure -a but this command hang here and the system reboots after few seconds... steakhutzeee@dk:~$ sudo dpkg --configure -a [sudo] password for steakhutzeee: Setting up containerd.io (1.6.33-1) ... EDIT: From armbian-config -> CPU (deprecated) I applied the max I could find. Now armbian-config states I'm running 1800-1800 MHz. I was able to successfully run the dpkg command and update my system. steakhutzeee@dk:~$ grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:155000 /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:userspace powersave conservative ondemand performance schedutil /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory I did: echo 1400000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq echo 200000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq If this issue with frequencies has to be fixed with an update, how can I set a correct frequency manually now? I'm afraid this high freq could cause damage actually. Thank you!

The default /. bashrc over rides any title or name setting set on the command line for all xterm and urxvt terms. This is very ugly and irresponsible behavior. I'm not sure where the source is kept but those lines of code need to be removed. Setting the prompt is one thing, smashing the title and name is something else.

@Blyato this is the other coin side of cheap tvboxes : devilish behaviour is just around the corner. If someone wants reasonable functions one must buy sbc well supported. That said unfortunately without original stock firmware, device tree or better the whole board in hands is quite impossible to guess what is going on Try to search on google or ask vendor for the stock firmware