Active threads

@Totof le Belge Is there any chance you could give an in-depth explanation of the user-overlay script? I'm trying to use a speaker that uses I2S with the GPIO pins.

Hi, TallMan, ...And here was me thinking I was all alone with my disillusionment of the way software has developed! I have to agree with most of your sentiments, with one exception. I have been a long time user of Linux (I stress user, as opposed to developer). This came about because more years ago than I care to remember, I worked for two major German companies on development of what was then known as Point-to-Multipoint communications, which later became the foundation for modern mobile phone network backbone communications. As part of this work, we had to carry out network planning for what are now the major phone network operators. Basically this consisted of predicting whether links would work under varying conditions (this was at frequencies up to 20 GHz). The tools we had to do this were the usual company Microsoft computer setups, satellite photographs of the area (in digital format), and a software tool written in Unix which used this data to predict lines of communication in 3 dimensions. This was my first experience of Unix, and it became a bit of a life-changer. Those of us who had to learn our way round it (as users), eventually all realised very quickly how much better/faster/more reliable it was than anything from anyone else, especially Microsoft. Of course, getting Unix for personal use at the time was not really on, but eventually Linus Torvalds produced Linux, and I for one never looked back. I'm well aware that users of Linux are regarded as nerds, and I'm happy with that, even if I try not to be one! As I got older, I eventually began to lose my interest in programming (another story!), but I am still a Linux user, and always will be. Its true it has its problems - but then all OS's have problems. In my opinion, sadly, these problems are not really the software as such - its almost always down to lack of information, or the proliferation of false and misleading information - after all, until recent years, developers set out with good intentions. Perhaps I can draw a parallel with my experiences in this thread using Armbian - While information and help does exist (Armbian documentation, for example), it is limited, and by no means comprehensive. It seems to be very difficult to make people understand that an OS is a tool, and should be usable, just like a screwdriver or a hammer, yet all too often the information to make productive use of the OS is simply not available. Instead, people like me rely on the good offices of people such as yourself - yet where would we be if the Internet didn't exist?. I do agree with you that even Linux is becoming 'overburdened' - but to some extent, that is one of its virtues - I have been able to make ancient computers run using Linux - Windows can't even make the transition from Windows 10 to Windows 11 unless the user buys a new machine. At least Linux has never declared good equipment obsolete, like Microsoft. It is easy for me to see a very close similarity between Armbian and Linux - I know this is intended, because of the Debian connection, so for people like me thats no bad thing. I can also see the attraction of RISC-V (probably too late for me to take it up), but one can hope these develop in a more organised, less monetised way than some OS's. Great to hear about the Commodore - a classic!. I still have my very first personal computers - a Sinclair Z80, which still works, although its keyboard has troubles. I got it around 1981, and it was one of the early self-assembly versions without a case. No-one was more surprised than me when the thing worked. Maybe I'll find another keyboard for it - I also have books giving its full ROM listing, and a circuit diagram, and 'advanced' programming - or BASIC in other words. Then I moved on to an Oric Atmos, produced in 1984 by Tangerine Computers (Shades of Orange!). It was a 'real' computer, with a proper keyboard, and used a Rockwell 6502. I did a lot of machine code programming on it, and very quickly changed the processor to a 65C02, which has a better, expanded instruction set. (in ths days, the 650s was often cited as having the first Reduced Instruction Set). I also still have it in working condition, plus a full ROM listing/circuit, and books on programming it (machine code). The BASIC it used was also very good. Later machines included a Dragon, Atari520 and some forgotten (perhaps for the best) . Like you the OPi is my first ARM device (actually given to me by a friend). I was interested in a Raspberry PI 5 (I have an old RasPi3), but they were so hard to get and expensive, I gave up. (I think the friend gave up on the OPi, which was why I ended up with it)! I also would have like to have seen most modern OS's lead to development of better systems, but I guess it won't happen in my lifetime, but at least I can support work on things like ARM and RISC-V. Incidentally, did you see that Qualcom won a case brought against them by ARM because techniques developed by ARM were allegedly used by Qualcom in their mobile phone processors? - probably not a good thing for ARM. And finally...I'm still stuck with this confounded stray icon on my Armbian installation, so another night searching for it.I 'm quite impressed otherwise - it seems very fast and efficient, (compared to my Ryzen7 Desktop machine) so I'll keep at it - It has most of the software on it that I need for now, so its definitely usable. I know about the hidden and system folders in Linux, and they are fairly easy to access in Linux Mint, but a search doesn't throw it up (yet) - I'll keep trying. Thanks for the Help, Keith

@Werner I agree that it's more convenient for everyone, but it took me some time to find out how and testing it in an image. https://github.com/armbian/build/pull/8707/commits

I transferred it on two consoles using armbian-config. There were no problems.

Hi @Dominik Wójt, Thank you for your time looking into this. I was really stuck in a loop looking for solutions and this is the conclusion I also came to: The issue is with the kernel, not with DTBs, config, distro, monitor or anything else. I got the output to work on a regular image by installing "linux-image-edge-meson" but still no access to NAND and the device does not run smoothly. Best experience I've had was with an old image with kernel 3.10.108 which had everything working and running smoothly. I would like to try these patches you mentioned but unfortunately I don't have the knowledge on how to do so, then how to put this into armbian during the build process... I've now given up on this. Installed LibreELEC with and old kernel and donated the box away. Though I want to thank you again for your suggestions and for your help.

I will rename it from ../../devices/platform/i2c-display/i2c-6/6-0024/leds/display-controller to ../../devices/platform/i2c-display/i2c-6/6-0024/leds/display an try again........

Werner : thanks for you best effort, will try it as soon as im back home ,cheers

Laibsch, I was running bookworm, though I updated to trixie to see if that solved the issue. I applied the fix from the github issue. Fancontrol service is running on trixie now, though the fan is still at 100%. Georges, I did not post on the Odroid forum, since I'm running Armbian and I assume they won't be able to help us. Thank you both for your help!

there are many good works being done thos days by the community kernel.zip data for H96 Max RK3566 Box # lsmod | grep i2c tm16xx_i2c 12288 0 tm16xx 16384 1 tm16xx_i2c i2c_gpio 16384 0 i2c_algo_bit 12288 1 i2c_gpio # ls /sys/bus/i2c/devices/ 0-001c 0-0020 7-0024 i2c-0 i2c-6 i2c-7 # ls /sys/class/leds/display brightness device map_seg7 max_brightness message num_chars power scroll_step_ms subsystem trigger uevent # ls -l /sys/class/leds/ lrwxrwxrwx 1 root root 0 out 3 14:29 display -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display lrwxrwxrwx 1 root root 0 out 3 14:29 display::alarm -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::alarm lrwxrwxrwx 1 root root 0 out 3 14:29 display::colon -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::colon lrwxrwxrwx 1 root root 0 out 3 14:29 display::lan -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::lan lrwxrwxrwx 1 root root 0 out 3 14:29 display::pause -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::pause lrwxrwxrwx 1 root root 0 out 3 14:29 display::play -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::play lrwxrwxrwx 1 root root 0 out 3 14:29 display::usb -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::usb lrwxrwxrwx 1 root root 0 out 3 14:29 display::wlan -> ../../devices/platform/i2c-aux-display/i2c-7/7-0024/leds/display::wlan lrwxrwxrwx 1 root root 0 out 3 14:29 input3::capslock -> ../../devices/platform/fd000000.usb/xhci-hcd.1.auto/usb2/2-1/2-1:1.0/0003:17EF:6099.0002/input/input3/input3::capslock lrwxrwxrwx 1 root root 0 out 3 14:29 input3::numlock -> ../../devices/platform/fd000000.usb/xhci-hcd.1.auto/usb2/2-1/2-1:1.0/0003:17EF:6099.0002/input/input3/input3::numlock lrwxrwxrwx 1 root root 0 out 3 14:29 input3::scrolllock -> ../../devices/platform/fd000000.usb/xhci-hcd.1.auto/usb2/2-1/2-1:1.0/0003:17EF:6099.0002/input/input3/input3::scrolllock lrwxrwxrwx 1 root root 0 dez 31 1969 led-power -> ../../devices/platform/leds/leds/led-power lrwxrwxrwx 1 root root 0 dez 31 1969 led-status -> ../../devices/platform/leds/leds/led-status lrwxrwxrwx 1 root root 0 dez 31 1969 mmc1:: -> ../../devices/platform/fe310000.mmc/leds/mmc1::

I use Balena Etcher on my laptop running Linux Mint. It never let me down before. I understand balena Etcher on an Arm SBC is not recomended. Ernst-Jan

it's a headless unit, Werner. if i can't ssh in then i just use an older build.

I think this "unsupported version" thingy when doing initramfs update is just a cosmetical thing. The script comes from upstream and checks for version string included in upstream (directly from Raspberry to say) kernels. However I believe this has been worked around by our own bsp which is silently executed right after. Cannot tell for sure if that's the issue I remember it is since I don't have access to hw atm.

Basically you as heads-up for upcoming kernel bump in this branch and everyone else for attention getting this merged (or not)

Good evening all and thanks @Igor for the suggestions. I managed to connect to my Cubox-i4 from my laptop via USB with sudo picocom -b 115200 -r -l /dev/ttyUSB0 and now I have lots of messages, but no success with booting the Ubuntu 24.04 Noble minimal image. In particular, there is a complaint about a CRC error. I've attached the text generated by letting the boot process run for awhile. I decided to try the Bookworm minimal image, and I'm up and running right away with that. So I guess I will stick with Bookworm for now. If anyone generates a new Ubuntu 24.04 image they would like me to try, happy to give it a go. Or of course any other suggestions! booting_ubuntu_cubox-i.txt

@amazingfate Do you know if its possible to use tha latest mali blob with wayland and vulkan support (g24p0-wayland-gbm) and at the same time use the rkmpp on vendor 6.1.115? I got everything compiled and seemingly working but when I try to connect to a stream, all I see is black screen. This is with the moonlight-qt client and an orange pi 5 plus (rk3588)

Having the same issue however your solution doesn't seem to work for me for whatever reason.

@Faheem328 Do you have free time? how much free time do you have exactly? we are looking for someone like you with a RK3528 box we are depending on him finding a weekend to dedicate to the community https://github.com/ilyakurdyukov/rk3528-tvbox he will help us by taking this repository and including it in armbian with a wonderful pull request let's talk?

@rockamal maybe you’ll have better luck with x96q lpddr3 https://github.com/NickAlilovic/build/blob/v20250306/patch/u-boot/u-boot-h616/159-add-x96-q-lpddr3-v1.3-defconfig.patch git clone https://github.com/NickAlilovic/build.git --branch v20250306 cd build pico patch/u-boot/u-boot-h616/159-add-x96-q-lpddr3-v1.3-defconfig.patch Change @@ -0,0 +1,191 @@ to @@ -0,0 +1,192 @@ add this to the bottom of the patch "+CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y" Then you need to include the secure boot patch. pico patch/u-boot/u-boot-h616/secure-boot.patch create the secure boot patch. you can find it here.

sorry for the delay, @mvpwar for RK3566 NPU you can use the original armbian DTB that enables NPU support: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3566-h96max-v56.dts I think you will take fragments from ancient builds like this: https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/page/16/#findComment-211031 I don't know what the status is in version 6.17 but we are still required to use vendor 6.1

Thank you for that additional information, Igor. The lack of desktop images is only a minor inconvenience, I'd say. Easy enough to install the required packages after installation of the base image to the SBC itself.

HW (features are determined by kernel used in the image) related issues are shared among all variants, desktop, cli, minimal, Debian or Ubuntu.

@Fredrik thank you for the reply. I wonder what's Gnome doing to initialize the audio that's different from a regular (non-graphical) boot. FWIW I installed also Pipewire/Wireplumber and tried to test the audio through the PW ALSA emulation, but that didn't work either. Just out of curiosity, does speaker-test work from the CLI once booted into Gnome or is it just the sound test in Gnome settings that's working ?

I troubleshooted my problem! So for some reason (I'm not sure if this is for all x88 pro 10's), the SD card needed to be under pressure on it to read Multitool. So, throughout the entire Multitool process, I needed to hold down the SD card with my thumb. I did hurt a bit, but it flashed to the EMMC

I retried that image now but with a different installation method, booting into OOWOW (?) via the Function+Reset button, control via serial debug console. I then wget the image from my local server and dd out to /dev/mmcblock0. Subsequent boot was indeed successful.

The three holes could be access to a serial console if necessary. Ground Transmit Receive. If you want to try this, baudrate is most likely 115200 like all Allwinner SoCs.