Igor

It has latest kernel support with good hw support. https://armbian.com/boards/jetson-nano

Thank you! It took few days and now almost everything works. If you can provide more data, I can try to fix problem you have. test without the video= options. Post armbianmonitor -u. Post the output of dmesg | grep -iE 'drm|tegra|sor|dpaux|hdmi'. Post the EDID for each port: cat /sys/class/drm/card*-DP-1/edid | edid-decode and the same with HDMI-A-1.

Nighly builds sometimes breaks. Do you notice this like "now" or on longer period?

Theoretically this way, but no warranty that it will work on this specific hw / sw combo: echo 1 | sudo tee /sys/class/graphics/fbcon/rotate_all Values: 0 normal, 1 90° clockwise, 2 upside down, 3 90° counter-clockwise. Keep it after reboot. Add the value to the kernel command line in /boot/armbianEnv.txt: extraargs=fbcon=rotate:1 And Welcome!

I'm afraid that doesn't extend to hardware bring-up kernels, aka vendor kernels. Security maintenance for vendor kernels is largely the responsibility of the SoC vendor. Since these kernels typically contain extensive out-of-tree modifications, applying upstream security fixes represent troubles - reain troublessome even with usage of AI as each code commit, still needs human (double) check. Even with mainline-based kernels, it takes time for security fixes to reach package repositories. However, the maintenance effort is at least shared across all hardware, while vendor kernels typically serve only a single SoC platform. Given our limited resources, comprehensive security maintenance of vendor kernels is simply not possible. We can't cover for them. If security and long-term maintenance are priorities, we recommend using a mainline-based current/LTS kernel whenever hardware support permits. If this is your business critical deployment and you need vendor kernek, I am sure one can find proffessional services that will provide this.

Generic Debian kernels might boot and even work as simple server case, but won't be close to support level of Armbian mainline based kernels. We are also doing automatic tests on hardware and verify certain functions. Examples: https://docs.armbian.com/status/board-tests/#rock-5t-01 https://docs.armbian.com/status/board-tests/#rock-5b-01 we don't have this specific device in the lab). Debian kernels, which you are reffering to, are not tested on hardware in such fashion nor anyone there maintain them. Its pure mainline. In repository look for kernels named "current" (latest LTS) and "edge" (7.x). Those are patched and tested but it is recommended to use current LTS for production. EDGE are more fragile and usually doesn't bring any features as we tend to backport them. Also worth trying: https://docs.armbian.com/config/kernel/ And one thing worth mentioned, vendor kernel 6.1.x are most feature complete, always. More recent version support less hw related features. Gap is getting smaller with time. tl;dr;

Perhaps add it here: https://docs.armbian.com/contribute/armbian-config/

No worries. Nothing changes by default. The separate ext4 /boot with EFI at /boot/efi only happens if you build with BOOTFS_TYPE=ext4 BOOTSIZE=XXX yourself. It's for people who need a bigger /boot for initramfs. Standard UEFI/GRUB images keep the usual layout: EFI at /boot/efi, and /boot on the root filesystem. No board config turns this on, so your shrink-backup script won't come across it in official images. It might still be worth supporting later, since a three-partition layout (EFI + /boot + root) is what Debian and Ubuntu installers create with LVM or encryption.

I was bored two weeks ago and ... https://github.com/armbian/build/pull/10988

Now we have a dedicated family and this is a good example of adding a new device: https://github.com/armbian/build/pull/11034

Thanks for your suggestion! Unfortunately, we cannot provide prebuilt images for every possible combination of board, distribution, and configuration. Building, testing, hosting, and maintaining all these variants requires considerable resources, so we have to prioritize the most commonly used configurations. The good news is that Armbian is not just a collection of downloadable images, but also a powerful build framework that allows anyone to create exactly the image they need. You can build a Debian 13 (Trixie) minimal server image for the Orange Pi 4 Pro yourself. Build instructions: https://docs.armbian.com/build-framework/ ./compile.sh BOARD=orangepi4pro RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no This flexibility is one of Armbian's key strengths. We encourage users to explore the build framework and, whenever possible, contribute improvements back to the project.

Your fetch pulled PR #11072, not #11084: pull/11072/head:pr-11084. #11072 still mounts EFI at /boot. That is why the kernel files are on p1. Revert your local grub.sh edit and run: git fetch origin pull/11084/head:pr-11084 git checkout pr-11084 ./compile.sh build BOARD=rock-5-itx ... ENABLE_EXTENSIONS=uefi-edk2-rk3588 BOOTFS_TYPE=ext4 BOOTSIZE=512 UEFISIZE=256 Expected result: kernel, initrd and grub/ on p2 (/boot), EFI on p1 at /boot/efi. Please report if it boots. I tested the image layout, not a boot.

I managed to bring Bananapi M4 / RTD1395 to latest mainline uboot and kernel in usable state. https://github.com/armbian/build/pull/11071 Booting still require to load some audio propriatery blob (don't want to boot without) ... so it remain a nasty port. But board is usable, at least for server tasks, even pci works, but I am stopping here. Perhaps, with some luck, this port could be usable for tv boxes based on this chip. FYI, no support can be provided.

Tnx. It is probably a problem of 1st boot configuration. I am aware this part is not among the best parts of the code and its refactoring or at least haredening is on the 2do list for awhile.

First fix was already merged. Try with this one: https://github.com/armbian/build/pull/11084