Search the Community

Showing results for tags 'uefi-arm64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • Tech News
    • Khadas VIM4
    • Radxa Zero 2
    • Odroid M1
  • Supported boards
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unsupported (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Old bug tracker - read only
    • Old bug tracker - read only
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Location


Interests

Found 2 results

  1. 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.
  2. https://www.armbian.com/uefi-arm64/ said it suppport PHYTIUM D2000, so i want to ask, if it support PHYTIUM FT2000/4 ?