Active threads

Thank you Werner. I'm not into Armbian enough to understand how the hardware is supported across all the kernel versions. The best I can do is to test different versions until I find the mininum support for the things I want to do. Till now, kernel 6.1.99-vendor-rk35xx works more or less, but SATA HDDs are not always detected at boot. HDMI output doesn't work for me when kernel 6.12 is used (I have rock 5 ITX - Board version 1.12). Kernel 15-rc solves the SATA support, but audio doesn't work. I went throught many webpages to check if I can solve some issues here and there, but my limited knowledge doesn't allow me to really understand what's going on and the interactions between elements of the system. I have to rely on the hard work of the developers community, waiting for better support in the future, if any.

tl;dr; It a business support / donation deal between Armbian and SBC maker. We have some budget, we aim on at least positive zero, and we have some people behind those boards. This doesn't mean we will be able to resolve all problems and in real-time as budget is still too small and resources remain limited. Support is better https://docs.armbian.com/User-Guide_Board-Support-Rules/ then on boards without.

Any updates on this? I am just trying to install Armbian on the eMMC of 5B. It’s not working, so I ran into this thread. If possible, I wouldn’t want to open the case (and undo the thermal tape) to access the maskrom button, so I was wondering if the you think the instructions of sns1801 could be adapted to constructing a new image with several invocations of dd? Then use any image on an SD to flash the custom image from a USB stick using dd?

Hi Everybody, I'm trying to set up Nextcloud with Collabora Office on NanoPi R4S running Armbian, but I'm having trouble configuring the reverse proxy (nginx/Caddy) for HTTPS with local domains. Current Setup: Running via docker-compose.yml (shown below) Without HTTPS, everything works: Collabora can open documents in Nextcloud's web UI With HTTPS enabled, Collabora integration breaks Added to /etc/hosts: 127.0.0.1 nextcloud.lan collabora.nextcloud.lan What I Need: HTTPS configuration for both services Reverse proxy to local domains: Nextcloud: https://nextcloud.lan Collabora: https://collabora.nextcloud.lan My docker-compose.yml (HTTP-only version): networks: network: driver: bridge volumes: mariadb_config: mariadb_data: nextcloud_config: nextcloud_data: services: collabora: image: collabora/code restart: unless-stopped container_name: collabora hostname: collabora domainname: collabora.nextcloud.lan networks: - network ports: - "9980:9980" cap_add: - MKNOD nextcloud_db: image: linuxserver/mariadb restart: unless-stopped container_name: nextcloud_db hostname: nextcloud_db networks: - network volumes: - mariadb_config:/config - mariadb_data:/data environment: - PUID=1000 - PGID=1000 - TZ=UTC - MYSQL_ROOT_PASSWORD=nextcloud - MYSQL_DATABASE=nextcloud_db - MYSQL_USER=nextcloud - MYSQL_PASSWORD=nextcloud nextcloud: image: linuxserver/nextcloud restart: unless-stopped depends_on: - nextcloud_db - collabora container_name: nextcloud hostname: nextcloud domainname: nextcloud.lan networks: - network ports: - "8080:80" volumes: - nextcloud_config:/config - nextcloud_data:/data environment: - PUID=1000 - PGID=1000 - TZ=UTC - NEXTCLOUD_UPLOAD_LIMIT=16G - NEXTCLOUD_MAX_TIME=3600 - NEXTCLOUD_MEMORY_LIMIT=3G - SKIP_DOMAIN_VALIDATION=true - NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.lan Key Questions: How should I modify the docker-compose.yml to: Enable HTTPS for both services? Properly configure the reverse proxy for the local domains? Set up valid SSL certificates for *.lan domains? For Collabora: What extra_params or environment variables are needed for HTTPS? How to configure Nextcloud's config.php for the Collabora HTTPS endpoint? I'd prefer a solution using Caddy if possible, as it's simpler for automatic HTTPS. Any working configuration examples would be greatly appreciated! Thanks in advance for your help! Viktor Malygin WordPress Developer

The software used by the Orange Pi "team" is, to a very large extent (estimates go as high as 99.9%), based on the work of developers from the Armbian project (and beyond). Their contribution mainly includes adding basic support for new boards, but unfortunately, without further maintenance or long-term support – which practically means that the entire burden of maintenance and support falls on the community. It should be noted that systems such as Orange OS Ubuntu and Debian on ARM architecture are the result of years of work by more than 500 people gathered around the Armbian project. Orange Pi only makes minor adjustments. In the past ten years, we have not seen a single contribution from any member of the Orange Pi team to the development of these key components. Absolutely nothing, while they keep signing under our work (even changed to some degree) ... on top of stealing software support. Which they don't provide in any way. The work of the Orange Pi team (which appears to be just one individual), on top of some old Armbian, can be tracked here: https://github.com/orangepi-xunlong/orangepi-build/commits/next (they removed other board configs)

i have a image working with some h616; you may try; i will give the link here

IIRC this was never integrated but was supported via community initiative:

Please take a look on CPU usage precision on the new kernel for x64 and arm64. It is 1 milliseconds. But kernel 6.13 on armv7 still provides 4 milliseconds of precision. How do I tune CPU usage precision on image build?

@Marco Cettina When you apply the overlay, the PWM driver will loaded and export some files to /sys. I haven't figured out what to do with it next or how to use it yet. I hope you can clarify this for all of us. PR: pull/8086

PanVK has reached a new milestone, and is now officially conformant with the Vulkan 1.1 specification on the Arm Mali-G610 GPU! The submission was done from the Mesa 25.0.2 release, and covers both armhf as well as aarch64 architectures. View the full article

/* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 /* Bit 1 express single-endedness */ #define GPIO_PUSH_PULL 0 #define GPIO_SINGLE_ENDED 2 /* Bit 2 express Open drain or open source */ #define GPIO_LINE_OPEN_SOURCE 0 #define GPIO_LINE_OPEN_DRAIN 4 /* * Open Drain/Collector is the combination of single-ended open drain interface. * Open Source/Emitter is the combination of single-ended open source interface. */ #define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) #define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE) /* Bit 3 express GPIO suspend/resume and reset persistence */ #define GPIO_PERSISTENT 0 #define GPIO_TRANSITORY 8 when combining add the bits #define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) is 2+4= 6 gpios = <&pio 0 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; or gpios = <&pio 0 7 4>;

Introducing Armbian’s New Cloud Images: Optimized for x86 and aarch64 Cloud Deployments Armbian is taking a significant step forward in cloud computing support with the introduction of dedicated cloud images tailored for cloud environments. The latest enhancement brings a new ‘cloud’ image set specifically designed to optimize generic x86 and aarch64 deployments, ensuring better performance, security, and compatibility in cloud infrastructures. Why Dedicated Cloud Images? As more enterprises and developers deploy lightweight Linux images in cloud environments, the need for a streamlined, cloud-optimized configuration has grown. The new ‘cloud’ images aim to address this by focusing on: Very Fast Boot Time: Optimized configurations enable boot times as fast as 1-2 seconds, ensuring rapid deployment and responsiveness. No Firmware Package: By eliminating unnecessary firmware packages, the cloud images remain lightweight and focused on essential cloud functionality. Optimized Performance: Stripped of unnecessary hardware drivers, the cloud images are leaner, allowing faster boot times and improved efficiency. Enhanced Compatibility: Fine-tuned configurations ensure that Armbian-based cloud instances run seamlessly across major cloud providers, including AWS and Azure. Security-Focused Design: With a minimal attack surface, the cloud images reduce exposure to vulnerabilities while maintaining essential features. Lightweight Image Size: The uncompressed QCOW2 image is approximately 700MB, ensuring minimal resource usage while maintaining full functionality. Docker Support Enabled by Default: The cloud images come preconfigured with Docker support out of the box, allowing seamless deployment of containerized applications. Lean Debian Bookworm or Ubuntu Noble User Space: Provided images come with a minimal yet powerful user space based on Debian Bookworm or Ubuntu Noble, ensuring stability and efficiency. ZRAM Management: Built-in ZRAM management optimizes memory usage, improving performance in resource-constrained environments. Armbian-Config System Configuration Utility: The powerful armbian-config tool provides an easy way to configure and manage system settings, enhancing user experience and customization. Customize and Brand Your Cloud Image Armbian makes it incredibly simple to create custom, cloud-optimized images tailored to your needs. Whether you’re an enterprise or an individual developer, you can brand and configure your Armbian cloud images to match your identity and requirements. Have always fresh Armbian OS with your brand! By leveraging the Armbian build framework, you can easily build your own cloud images with custom configurations, packages, and branding. Get started today by visiting the official Armbian build repository. Build command example: ./compile.sh \ BETA=no \ BOARD=uefi-x86 \ BRANCH=cloud \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ ENABLE_EXTENSIONS=image-output-qcow2 \ IMAGE_VERSION=25.2.3 \ RELEASE=noble \ VENDOR="Company" \ VENDORCOLOR="5;100;115" \ KERNEL_CONFIGURE=no \ KERNEL_BTF=yes Download links You can find download links at https://www.armbian.com/download/, or use the direct links below. For the QEMU disk image (QCOW2) format: https://dl.armbian.com/uefi-x86/Bookworm_cloud_minimal-qcow2 https://dl.armbian.com/uefi-x86/Noble_cloud_minimal-qcow2 https://dl.armbian.com/uefi-arm64/Bookworm_cloud_minimal-qcow2 https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-qcow2 and Microsoft Azure image format: https://dl.armbian.com/uefi-x86/Bookworm_cloud_minimal-hyperv https://dl.armbian.com/uefi-x86/Noble_cloud_minimal-hyperv https://dl.armbian.com/uefi-arm64/Bookworm_cloud_minimal-hyperv https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-hyperv How This Benefits Cloud Deployments This update makes it easier for developers and businesses to deploy Armbian-based instances in the cloud without unnecessary bloat. Whether running on AWS, Google Cloud, Azure, or smaller providers and Qemu KVM / Proxmox, users can expect: Reduced overhead and better resource utilization Improved stability with cloud-centric optimizations A more agile and lightweight system for containerized applications Faster provisioning and deployment due to the ultra-fast boot times Seamless container orchestration with pre-enabled Docker support Optimized memory management with built-in ZRAM support Customizable and user-friendly system configuration via armbian-config The ability to build fully customized, branded cloud images with ease What’s Next? Armbian continues to evolve, ensuring that users benefit from its embedded Linux roots, embracing a philosophy of minimalism and efficiency that ensures optimal use of system resources. Community feedback is crucial in refining the cloud images, and we encourage users to test them out and contribute. For more details, visit the official Armbian GitHub repository and join the discussion! Stay connected and experience the next generation of Armbian cloud support today! The post Armbian cloud images first appeared on Armbian. View the full article

Since u-boot can deal with the original initrd.img, do we still need to convert it into uImage?

Indeed, the patch was for 32bit chips, I did not look too careful. But it touches the clk-pll.c which is common. Not sure if it is worth to try to apply it to the rockchip64 series. I had a similar issue with tinker board (rk3288) where the mainline kernel did not work with some HDMI panels but the vendor kernel did. In both cases I had EDID warnings. The problems was caused by clock issues.

Since we host these sources ourselves, you can directly pr against them:https://github.com/armbian/linux-rockchip

No, I just made a few modifications to make it work on this board.

i'm writing this from an aarch64 chromebook running mainline linux with 32gb of emmc (usually 90+ % full) which i'm using as daily driver for over two years now with firefox having many dozens of active tabs open all the time, so that its usually about 1gb into swap with its 4gb of ram (despite using zswap memory/swap compression) and so far it is running fine without problems und due to the btrfs internal checksumming on read those would be visible immediately ... same applies to a few small servers with a similar setup running from a1 rated sd cards, all fine as well ... this is not armbian, but btrfs (which should be the same everywhere) - maybe formatting with "-m single" and mounting with "ssd" option might be a good idea (at least this is what i use on above mentioned systems).

Ok, that way 😁 I've an old USB-to-serial debug device. This article states that the Rock 5 ITX works at 1,500,000 bps and my iron doesn't reach that speed. I gave it a try and indeed nothing on the screen because the max baud rate is lower than the needed one.

arecord -f dat -D plughw:analog Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo arecord: set_params:1416: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: 125000 PERIOD_SIZE: 6000 PERIOD_BYTES: 24000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 24000 BUFFER_BYTES: 96000 TICK_TIME: 0

@going Thanks for your process. I followed it, and using userpatches makes sense. However, upon installing the new kernel my config changes are still not present. So I reviewed the kernel build log and I see why: --> (12) COMMAND: ./scripts/config --enable RT_GROUP_SCHED Which happens are my userpatch file is copied over. I wonder if I have control over this process?

Was anybody able to install to emmc on this unit? I can't do it with nand-sata-install. It only shows my SD card.

Thanks for the reply. Yeah I knew from the start since it also advertises Android 14 yet it's last updated in 2019. Already got a refund back so I'm good. Just thought maybe I can get it to work and give it to a friend, hence why I'm trying to get it running properly. Tried some H313 firmwares but none seem to update (getting a incompatible rom error).

Installing `libegl1` makes weston run, but GPU is not used, rendering is done via software mesa.

The following has resolved the issue for me: armbian-upgrade sudo apt remove libraspberrypi0 libraspberrypi-bin sudo apt update sudo apt upgrade thanks to geoW here: https://help.nextcloud.com/t/internal-server-error-after-php8-3-upgrade-on-12-apr-ncp-1-55-3-on-rpi5/222576/2

Bluetooth app opens and scans but does not find any devices.