Active threads

@royk Finally working for the spi bus. As I didn't know what I may did wrong, I reinstalled the system, read better the doc as you suggested (the first example they show it's not the standard configuration, confusing for me at first), and finally I chose the right overlay. My armbianEnv.txt is like this to make it works: verbosity=1 bootlogo=true overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588-orangepi-5-plus.dtb rootdev=UUID=2cc7a9a6-afc7-4cd4-b377-6f83f2e1bf50 rootfstype=ext4 overlays=rk3588-spi0-m2-cs0-cs1-spidev usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I'm using the cs0-cs1 because I will need both later as I will use rotary encoders. I assume it will be the same for i2c bus, I will have to choose the right overlay. I still don't know which one would be for the i2s, but I should find that somewhere in the documentation I hope. Thanks for the answers and the tip for how to load user overlays.

Thank you, Werner. I was doing "clang 16 armbian" and trying to see if there were prebuilt packages...

@TheGuv Your CPU governor setting is set to performance, while I am using the standard settings (see below). You may safely upgrade linux to 5.15.52. Although it uses the r8152 mainline driver v.1.12.12 it is stable. To figure out what is wrong with your system you should start from a fresh image (bookworm 23.05.4-6.1.36) and downgrade to one of the linux versions 5.15.93, 5.15.52 or 5.10.43 if you have problems with 6.1.36. Im am currently using linux 5.15.52. # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

hi, make sure you have all the kernel modules in your initramfs as listed here: https://github.com/NixOS/nixos-hardware/blob/master/pine64/pinebook-pro/default.nix i had the same issue with my archilnux installation until i included all of them

Hi @NiTr0, it seems you were able to successfully boot Armbian on a Hongtop H20 tvbox. I'm trying to the same with Librelec, but I have similar issues as you had (boot stops after loading trustos). Can you please summarize briefly me what have you done to solve the issue? Thanks a lot.

As nobody maintains helios64, installing Armbian updates is like playing russian roulette (even worse than that). In the parallel thread I tested various combinations of OS, bootloader and kernel and ended up with this configuration (adding linux 5.15.52 to the list).

Hello. Do you have multitool for RK3128 ? I can't boot my mxqPRO 4K5G from SD card. Monitor start blinking and tv box firmware die (need restore from backup). TV box work fine. I have boot.img and other files from this chip .

wifi works, with remove sd-uhs-sdr104; or change it to sd-uhs-sdr50; but bt still not work: [ 23.521445] Bluetooth: hci1: BCM: failed to write update baudrate (-110) [ 23.522130] Bluetooth: hci1: Failed to set baudrate [ 25.541403] Bluetooth: hci1: command 0x0c03 tx timeout

Description Small followup fix https://github.com/armbian/build/pull/6006 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] Compile and boot rk3318-box from second partition Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description The "optional/boards" directory seems to have been deprecated and actually never used so much. Remove the last board support package there (rk3318-box) and move into extension as suggested by @rpardini. Ancillary BSP files have been removed too. The extension may have global interest because it was a workaround for X.Org and Lima driver: the former was not able to autodetect the latter with some revision combinations. That configuration fixes the autodetection. At the moment, it has been enabled in rk3318-box board and rk322x family. How Has This Been Tested? [x] Compile debian bookworm image for rk3318-box and verify 40-serverflags.conf presence [x] Compile debian bookworm image for rk322x-box and verify 40-serverflags.conf presence 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] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

That is intended to work that way, for an important reason: the bootloader is not just a mere bootloader, but installs complex code in memory and you don't know what it does. More on that: that code runs in a secure context, which is not accessible by anything, so you really don't know what it does and what it can do. One clear example is the fact that the stock bootloader artificially blocks the rk3318 when it runs beyond 1.1ghz, while we have seen it is pretty capable of running at 1.3ghz perfectly fine like the rk3328. The idea is to remove as much as possible of the proprietary blobs (ie: the stock bootloader) and provide open alternatives; tinkering with the bootloader may work now but surely will cause troubles when there will be an updated bootloader. Your case with broken emmc is a different condition by the way, because you have limited alternatives. However there are no real secrets in the boot process, just some complexities and some of them are explained here

Rockchip software development is focused to deliver Android / hardware showcase experience, not for real Linux OS implementation. Their upgrade from 5.10 to 6.1 brings very little of what you are hoping for. This has some technical gain, while majority is marketing value to support hardware sales. Real software support is on us, community and various Linux kernel professionals that are operating in this segment. Anyhow, we will maintain the tool that helps you implement it. We already implemented mainline based support and that we will maintained in best effort manner. Similar as it works today - all functions of the SoC will never be covered and maintainace will depend on your support or absence of it. Our automated testing facility shows no problems (btw. test images, which could be broken, are for developers only) https://github.com/armbian/os?tab=readme-ov-file#orangepi5-plus How to boot Armbian: https://docs.armbian.com/User-Guide_Getting-Started/ How to report problems: https://www.armbian.com/bugs Support us, so we can sponsor people that sold you hardware: https://liberapay.com/armbian

https://www.armbian.com/compatible/ Here you can check a selection of compatible devices, usually in some personal / Armbian use. You probably don't need 16 port USB hub which is on that list, but that will certainly work perfectly. If you go for some cheap variants, and most of hubs are a lot cheaper, you will be chasing luck. For my purpose, automated testing of USB devices withing Armbian, I can't use cheap ones.

"Virtual disk images (such as VHD and VMDK) are intended to be used for cloud computing," https://en.wikipedia.org/wiki/IMG_(file_format)#Comparison_to_ISO_images Our build framework can generate cloud images directly https://github.com/armbian/build/blob/main/extensions/image-output-vhd.sh in case you need to automate this and you don't want to mess with additional scripting. ./compile.sh ENABLE_EXTENSIONS="image-output-vhd" Try using dd and copy entire image from USB to /dev/vdi or whatever disk device is. Please provide armbianmonitor -u and if you want to look into & help in this context, here are sources. You are also welcome to open a ticket and we both can hope someone will fix this soon. Even its probably just one-line fix, someone needs to find that line, test it to make sure it works and open a pull request.

Description As per title. How Has This Been Tested? [ ] Build test at CI Checklist: [ ] My changes generate no new warnings View the full article

Original version destroyed journal on command postrotate as files in /var/log.hdd/journal are overwritten by cat. With the patch journal is not damaged anymore. Description In original version in postrotate files in /var/log.hdd/journal are deleted by the command dest="/var/log/$file" cat $file > $dest as /var/log/journal is a symling to /var/log.hdd/journal files are cated on themselves which ends up with an empty file. How Has This Been Tested? check journal by journactl. There is no data earlier than today 0:00. Also "journalctl --verify" shows that journal is damaged. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Sorry, it will be quite long 🙂 I have three HC4 devices: odroid1: Linux odroid1 5.10.57-meson64 #21.05.8 SMP PREEMPT Mon Aug 9 12:44:31 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux ata-Samsung_SSD_870_QVO_1TB ata-Samsung_SSD_870_QVO_1TB odroid2: Linux odroid2 5.19.17-meson64 #22.08.7 SMP PREEMPT Thu Oct 27 18:34:08 CEST 2022 aarch64 aarch64 aarch64 GNU/Linux ata-Samsung_SSD_870_QVO_1TB ata-Samsung_SSD_870_QVO_1TB They run the kernel which recognized both discs AND there was ZFS support when I installed them. odroid3, currently used for some experimenting: Linux odroid3 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 GNU/Linux odroid3 recognises those disks: ata-Samsung_SSD_840_EVO_120GB_S1D5NEAD710633R ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R I replaced the ata-Samsung_SSD_840_EVO_120GB_S1D5NEAD710633R by another Samsung SSD_860_EVO_250GB It is not recognized, and in the /var/log/kern.log I see this: odroid3 kernel: [ 2.692110] ata1: SATA max UDMA/133 abar m512@0xfc700000 port 0xfc700100 irq 27 odroid3 kernel: [ 2.692124] ata2: SATA max UDMA/133 abar m512@0xfc700000 port 0xfc700180 irq 27 odroid3 kernel: [ 3.005134] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.478833] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Disconnected the ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R and rebooted NO ssd! /var/log/kern.log: odroid3 kernel: [ 2.901128] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.213129] ata2: SATA link down (SStatus 0 SControl 300) Tried both SATA slots, same results. Tried another Samsung SSD_860_EVO_250GB, same results, no SSD. The same "SATA link down" message. I bought a Crucial 1TB just to change manufacturer: ata-CT1000MX500SSD1_2249E68F3955 Works in both SATA slots. Rebooted again with ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R and ata-CT1000MX500SSD1_2249E68F3955 The last one in not there, the same messages in /var/log/kern.log. Two days later I rebooted it to try libata.force=noncqtrim kernel parameter and both disks are there. Removed libata.force=noncqtrim from armbianEnv.txt rebooted again, both disks are there. Then shutdown, power off/on and boot, no CT1000MX500SSD1. I tried the SD-card from odroid3 in the odroid2 and there both Samsung_SSD_870_QVO_1TB are there. Rebooted few times, just in case 😉 they were always there. Then disconnecte those two disks and connected the CT1000MX500SSD one: no disk after reboot. Put the SD-card in odroid1, only one disk, Samsung_SSD_870_QVO_1TB, is there. Replaced one of Samsung_SSD_870_QVO_1TB by CT1000MX500SSD, both are not there: kern.log: odroid3 kernel: [ 2.940933] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.252903] ata2: SATA link down (SStatus 0 SControl 300) I like the HC4 (when it works 😉 so I ordered another one hoping it will not have any problems. Got it today (I must be one of the best HK's custommers: H3, H3+, 4 x HC4 🙂 booted with a EVO 860 250GB SSD: uname -a Linux odroid4 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 GNU/Linux No SSD there. Re-plug it (I know the riscs) and lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 232.9G 0 disk Rebooted. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 232.9G 0 disk Rebooted again and the SSD is there. Aha, rebooted, not powered off/on. init 0 remove power 10 seconds connect power The SSD is there. init 0 Connected the CT1000MX500SSD, boot. lsblk -> no SSD. Somehow it doesn't make any sense, I don't see any regularity in all this. Did again hotplug ~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk Some time ago I already reported the problem with SSD's not being recognized. And the strange thing is, some of the events are quite random. The SSD is there, than not there. Now I would say: HC4 and kernels newer than 5.19.17-meson64 don't want to cooperate correctly. Who is the culprit? I don't know, don't have the necessary skills to debug it. However, I would love to provide all infos needed which HK needs to analyze the problem. Screenshots, etc. BTW, rebooted odroid4 again, no SSD. Regards, Chris

Description As specified in PR https://github.com/armbian/build/pull/5967, there was a nasty mistake in rockchip and rk322x source files that were attempting to create two groups (gpio and i2c) on the building host instead of the built image. This caused the build system to crash when the groups were already present on the building host, which is totally not desiderable, and the intended feature was also broken. After some inspection, the groups were leveraged by a couple of udev rules to allow non-root users have access to gpio and i2c resources out of the box. This PR fixes the group creation on the target built image. Note: gpio and i2c gids starts from 900 because gids nearby 1000 are already taken by some existing services. Note 2: this supersedes https://github.com/armbian/build/pull/5967 which can be closed as well. Jira reference number AR-1935 How Has This Been Tested? [ ] Compile debian bookworm for rockchip family, verify the presence of groups in target image [x] Compile debian bookworm for rk322x family, verify the present of groups in target image 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] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Issue solved (primitively but effectively) I have simply replaced the Armbian_23.11.1 meson-gxl-s905x-p212.dtb file in boot/dtb/amlogic with the same file from Armbian_20.10. A new "Built-in audio stereo" soundcard has appeared in the Volume Control window. Its port is labeled "Analog Output" but, in fact, it works on HDMI. I believe that the old and new dtb files are very similar but the Armbian_23.11.1 has dropped support for whatever version of the soundcard I have. This is not so surprising given that my YUNDOO Y6 was probably made in 2014-2015.

Description This PR fixes EXTRAWIFI=no compilation when uwe5622 driver and rockchip64 family is involved. The error was due to the fact that uwe5622 driver has been moved in misc patch directory some time ago, but a custom patch was left into family kernel patches to adapt the driver to rockchip64 platform. EXTRAWIFI=no would not patch the kernel to include the driver, but the custom patch was still applied since it was present as kernel patch and that would cause a failure. With this PR, the custom rockchip patch has been moved into misc directory as well and it is applied selectively in code, so EXTRAWIFI=no works correctly. Also uwe5622 related patches are moved into an wireless-uwe5622 subdirectory to tidy up a bit the misc directory Jira reference number AR-1925 How Has This Been Tested? [x] Compile rockchip64 current 6.1 kernel and run kernel on existing system [x] Compile rockchip64 current 6.1 kernel with EXTRAWIFI=no [ ] Compile rockchip64 edge 6.6 kernel [ ] Compile allwinner current 6.1 kernel 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] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

We registered the #armbian channel on the OFTC IRC network. It has been added to the bridge so message will be relayed to Libera and Discord. Depending on how frequently it will be used other channels like those for SoC or off-topic will be added later. Thanks @yang for the suggestion

moved

@Ya_super_grafiti dts/dtb files are specific to the linux kernel. Armbian focuses on mainline linux kernels and others out there use vendor kernels (which usually are a ported android based kernels from ancient sources). The differences between vendor kernels and mainline linux are usually significant preventing direct reuse of a dts/dtb from one to the other. If you know how dtb's work and have the hardware specs, you could port the dts into mainline, but that is expert level work.

@Silv3r_18 Welcome. Anything is possible, but it won't be easy. Search for other threads in the forum about TV Boxes and H616 support. Also read this FAQ item to understand that allwinner on TV Boxes is the least supported as there is no one that is actively focused on that cpu family on TV Boxes.

Thanks for the tip! Our current dirty hack is not even that and anyway doesn't work. You are welcome to remove that patch an add this one. Once merged, I can enable hardware on automated testings to see long term effects.