Skip to content
  • I gave this a shot, but the patch didn't seem to apply cleanly. So I applied the intended changes manually and then ran it but got:

    [mkarchiso] ERROR: Bootstrap packages file 'bootstrap_packages.x86_64' does not exist.
    [mkarchiso] ERROR: uefi.systemd-boot is not a valid boot mode!

    Not sure why it's not finding the bootstrap packages file since it does exist..

  • @bschnei, it sounds like you didn't checkout the branch.

    I forgot to add Server = to pacman.conf, which I now fixed, but that wouldn't cause those errors.

  • Yup that must have been it! Sorry! I was able to build the bootstrap. I'm missing a few packages for armv8 to do the full iso so I'll add them to my todo list :)

  • @nl6720 Great work! I have a successful boot @ c349140c on my X13s with a small patch.

    Some notes: As it stands, systemd-boot does not support compressed kernels on aarch64, and they have no intention to do so, hence vmlinux. (I haven't tried the EFI_ZBOOT workaround)

    Most ARM machines that run Linux use Device Tree (dtb) rather than x86-style ACPI. If there was a way to support this (Perhaps another flag in the profile + "%EXTRA_OPTIONS%" variable in the bootloader entry options line?), that would be nice. See my patch's hardcoded workaround.

    Edited by Alex R
  • I use EFI_ZBOOT and my fork of linux enables this option for exactly this reason. That is, so that we can package linux for aarch64 the same way we do for x64. Another workaround is to use grub which will decompress a kernel.

    Regarding dtbs, we probably should create a package linux-dtbs that will install them to /boot/dtbs for devices that require them. The "modern" solution that U-Boot supports seems to be to source the dts from linux directly and then bake it into into the firmware (u-boot) itself. A kernel then launched via EFI (whether directly from U-Boot or chain loaded via systemd-boot or grub) will find and use the device tree without any extra command line options or configuration. The downside is if a manufacturer makes fixes to their device tree, you'd have to flash your firmware to receive the update vs simply upgrading a package like linux-dtbs.

    In general, ARM devices seem to need a lot more "special" configuration via command line arguments to boot vs x64. This will make supporting them in general much more complicated than x64 and it's likely we'll need a wiki or some place for users to share/find the options they need to get even a generic ISO to boot their device and/or display anything on a serial console. ALARM bakes a standard console=ttyAMA0 into their kernel config, but that doesn't work universally :/

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment