Search the Community

Hi community, Context I build my own custom Arabian image on arm 32bit (prod), and experimenting running the following armbian image configuration on Qemu with console/serial only support for uefi-x86 and uefi-arm64 boards to speed up development/test. Problem I stumble upon something odd: both "uefi-*" boards are configured to only run GRUB in gfxterm mode ONLY. BOARD: uefi-86 -> BOARDFAMILY="uefi-x86". -> UEFI_GRUB_TERMINAL="gfxterm" [0] BOARD: uefi-arm64 -> BOARDFAMILY="uefi-arm64". -> UEFI_GRUB_TERMINAL="gfxterm" [1] [0] https://github.com/armbian/build/blob/2afd8fe9bb8aca33a2a3913e931fc43c43c8e309/config/sources/families/uefi-x86.conf#L11 [1] https://github.com/armbian/build/blob/2afd8fe9bb8aca33a2a3913e931fc43c43c8e309/config/sources/families/uefi-arm64.conf#L10 Image built from these boards should be runnable as CLI image (no gui) or Desktop image (gui). However, when running with qemu -nographic ... these image can't boot up to a working shell and produce an error: "GRUB: gfxterm is not supported" Proposed change I would like to submit a patch to change UEFI_GRUB_TERMINAL to "gfxterm vga_text console serial" to cover a large set of virtualised hardware configurations. 1. Is this something you guys are interested in ? 2. Does this fix need more than the proposed change to achieve the desired objective ? Thanks

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build". - improved support in GRUB (armbian wallpaper) & HiDPI GRUB support - all preinstalled applications are normal apt packages - current 5.15.y kernel, Jammy userland (5.19.y has some strange issues) - snapd is not installed (user can install it) - HiDPI support (automated adjustments on big screen resolutions) - NVIDIA graphics acceleration with proprietary driver (x86 only) - Intel graphics acceleration also works out of the box - preinstalled Google Chrome (x86 only) - preinstalled Microsoft Visual Studio Code (x86 only) - ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms) - face unlock works perfectly fine on this laptop - installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it). I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome. Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy. https://www.armbian.com/uefi-x86/ https://www.armbian.com/uefi-arm64/ Please report where it works and how (well)!

https://www.microsoft.com/en-us/d/windows-dev-kit-2023/94k0p67w7581 UEFI can be way how to boot it maybe

Test version of the Armbian+EDK2 system (UEFI\grub) is available. The system startup control is performed as on a regular PC - through the menu on the monitor screen, therefore, to fully use all the features of selective startup, you need to have a connected monitor and keyboard To use this option. Download the EDK2 image. https://users.armbian.com/balbes150/edk2/ https://disk.yandex.ru/d/kK6KIqHShRHLyw Unpack and burn to SD card. Download the Armbian image (kernel 6.1.0-rc7), For Station M2 https://disk.yandex.ru/d/C4Ql9v0BvhKPjQ For Station P2 https://disk.yandex.ru/d/5XuGz9WgF7FGCg unpack and burn it to a USB drive (8-16GB flash drives are recommended, I haven't checked other options). Connect the SD card and USB drive. Turn on the power. If the system does not start immediately, go to settings and select the device to start. On the EDK2 boot screen, select "Maintaining Manager boot" in the menu item and configure the device used for startup in it (change "none" to "UEFI ...."). Select Reset. If you did everything correctly, after restarting EDK2, you will receive a GRUB menu with a choice of system\kernel. If you do not select anything, the default system will be started in 5 seconds, and in 10-20 seconds (depending on the type of USB flash drive) there will be a standard Armbian customizer for the first launch. If desired, you can place the entire system on an SD card, but additional steps will be required at startup. At startup, the kernel switches the UART console to the correct value for RK (1500000) and you can monitor the kernel startup process and control the system through the UART console. That is, the parameters 115200 can only be useful for viewing the primary output from EDK2 itself, but this is only necessary for developers, for ordinary users, kernel output and system management are more useful, so I recommend using the standard value for Rockchip of 150000. https://github.com/150balbes/edk2_uefi

I'm writing from a limited perspective, so constructive criticism appreciated. In this thread, I'm recording some thoughts about how the OS gets from files into the memory of various boards, and what might make this more unified and easier and/or more flexible. Current U-boot My knowledge comes from the mvebu64 and rockchip64 families. At this time, the board boot process starts from code in the processor that attempts to find u-boot, and u-boot runs a script from its environment that searches for a UEFI application or a boot.scr file. They call this "Distro-boot" Armbian uses the boot.scr to load an uncompressed kernel image and a compressed initramdisk, along with a device tree. These use u-boot legacy image format. U-boot then passes control to the kernel. On mvebu64 (espressobin), u-boot is contained within the SPI on the board, along with its environment. U-boot 2022.04 on this board can do network booting as well as searching emmc, sd, or sata devices for a boot device based on a GPT type or simply the existence of files within the first partition on each device. On rk3399, some earlier stage attempts to launch idbloader from sector 64, which loads u-boot.itb from sector 16384, from whatever device can be detected: SPI, USB, eMMC, SD. The boot.scr loads the legacy uboot images from the first partition on the device, then applies overlays - I believe this enables HATs on boards that can use them. U-boot capabilities Boot process: UEFI. U-boot can load the linux kernel through the UEFI stub, or the GRUB bootloader. As far as I can tell, it's not a drop-in replacement for a legacy kernel boot. Boot file format: Flattened uImage Tree. This is a monolithic file that has one or more of kernels, initramdisks, and device trees, along with "configurations" that can be selected to tell u-boot which files to actually load. Additionally, the components of this file can be compressed, as u-boot can uncompress the kernel before passing control. Boot media: dhcp(v6) to tftp. U-boot can attempt to boot an EFI application from tftp, before it attempts to run a script from dhcp, before it attempts to PXE boot. Extlinux script: u-boot can read /extlinux/extlinux.conf where a menu of kernels can be provided, with paths to kernel, initrd, and dtb, and an entry for the cmdline. Each kernel on the system would need to contribute a fragment of this config, which isn't currently done. Image Layout Currently, many armbian images use an MBR partition table. It's the default, and a device needs to request GPT during the build to get it. But with GPT come a few advantages. The systemd/freedesktop people seem to have a vision of a single layout that would allow a linux system to boot on several architectures, and then auto-configure based on "discoverable partitions". There are partition type uuids for such things as ARM64 root partition, or dm-verity superblock and signature partitions. These features would give a read-only, integrity checked, signed image. There are partition flags for things like "read-only" (60), "no auto" (63), or "grow-file-system" (59). Beyond this, the ESP (EFI System Partition) has a structure to allow multiple kernels/OSes to deconflict the storage of their files. Boot Sequence Type #1 Boot Loader Specification: $BOOT is the (typically) vfat partition with type "bc13c2ff-59e6-4262-a352-b275fd6f7172", or the ESP (VFAT, "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"). Under $BOOT/loader/entries/, there would be files (e.g. ${machine-id}-${uname -r}-${os-release}.conf) that give configuration to find kernel and initrd at $BOOT/${machine-id}/${uname}/{linux,initrd,dtb,dtbo} Type #2: Unified kernel image - EFI PE w/ stub loader, initrd, and commandline, and can be signed cryptographically. These are at $BOOT/EFI/Linux/*.efi I assume these are handled by GRUB, as they do not seem to match u-boot's distro-boot. Armbian currently uses the boot.scr from u-boot's distroboot sequence to boot off the filesystem where boot.scr was found. First-boot and nand-sata-install When armbian builds the image, it does so through chroot and debootstrap. This results in artifacts like /etc/machine-id or /etc/ssh/ssh_host_*_key, which shouldn't be on multiple systems. They're removed as part of the image creation. Partition UUIDs ought to be changed too, but these are less likely to be a problem. The nand-sata-install attempts to create partitions to make a filesystem on some other block device, and then rsync's the running armbian system over to the new block device. It also tries to manage the u-boot bootloader and all the possible ways that can exist. (Goal) SD card partitioning sgdisk -n 14:${biosstart}:${biosend} -c 14:bios -t 14:ef02 -n 15:${uefistart}:${uefiend} -c 15:efi -t 15:ef00 -n 1:${rootstart}:0 -c 1:root -t 1:8305 -A 1:set:59 ${SDCARD}.raw This produces a GPT-formatted disk with the first partition (numbered 14) with a BIOS type (recommended 1 mb, or covering u-boot and files), an ESP (recommended 550 MB, to mount on /efi/), and an auto-detected ARM64 root partition that is labeled to grow to fill the disk when booted. Linux should be stored in a UEFI or FIT image, preferably as a UEFI boot method. U-boot environment variables for a given board should be able to select the appropriate armbian kernel, allowing the root filesystem to have multiple kernels for different boards installed and an SD card that boots on multiple boards.

Test version with EFI\Grub support (with HDMI output) for rk3399. for station p1 https://disk.yandex.ru/d/HZ34T76zxS9pnw for nanopc t4 https://disk.yandex.ru/d/SjBMYJ37U6699A firefly-rk3399 https://disk.yandex.ru/d/BfrzRRyvdtavIg

https://www.armbian.com/uefi-arm64/ said it suppport PHYTIUM D2000, so i want to ask, if it support PHYTIUM FT2000/4 ?