You are not logged in.
U-Boot can now run EFI executables and it is possible to run the EFI variant of Grub 2 from U-Boot. Four years ago, there were already some boards that were able to boot Linux using Grub 2 (EFI) and U-Boot: https://www.suse.com/media/article/UEFI … U-Boot.pdf (The list is in section V)
In other words: The abstraction layer that U-Boot provides through the EFI boot process could make it possible to provide generic Devuan GNU+Linux ARM installer images without hardware-specific boot code. The latter could be put in separate (small) image files for each hardware in case one needs to install the boot firmware (blob + U-Boot).
Are there plans to build generic installer images for ARM that use the EFI boot process?
Offline
hello mstrohm,
Apart from RaspberryPI that still need some blobs,
Devuan uses Free and Open Source Software with completely reproducible results by any person that wants to compile the code..
This was to clear a bit the Idea of blobs in Distros,as far as I know, Devuan are usually not in favour of blobs..
Speaking about EFI, the question here is what it brings of new?
And this for me is a big Question..
Because till now what people are thinking is that, they want to boot u-boot so that later start other bootloader on top of that( Grub )..
The problem starts with SBC's being small devices with less memory than desirable, and also a lot less Raw cpu power..
So the Idea is maybe a small bootloader..
u-boot itself is not a small bootloader by any means, it supports a plethora of hardware, and has a plethora of drivers, that are even people, only running a application only on top of it( without the linux vm..).But, after compiled for a determined board, its size is very acceptable.
uboot also supports, extlinux like boot,
Which is a simple way to boot(I personally prefer the 'boor.scr' script because its a lot more powerful and customizable.. ).
In any case, you will always have 2 different things, the bootloader, and the kernel to boot.
You can choose to have 1 partition or several( typically 2 partitions, one for /boot , and one for / ),
But you always have one bootloader compiled for 1 single device.. unless you have several boards , all being the same model..in this case the bootloader from one board is good for the other one( not always, because of the Hardware revisions on them..sometimes they also differ.. ).
So Devuan, for Installer Images, has 2 components, one being the bootloader part, and the other being the rootfs of the installer..
You combine them together and form one single installer image.
You can see them here in the README.txt.
One good example are the netboot ISO's option.
So, Devuan already provide the kernel + UserSpace, in a Generic Way,
If you look into those netboot isos, you will find out that there are a common to all boards part.
At same time, that are 1 part that depends on the board were the final iso will run..
In Other Words, Devuan already have that solution.
Last edited by tuxd3v (2021-01-31 10:02:33)
Best Regards,
tux
Offline
Speaking about EFI, the question here is what it brings of new?
EFI would allow building an installer image once without having to care about the specialities of the hardware. That's what an U-Boot that is already installed on the machine (in on-board flash for example) would do. The installer image would just contain Grub and a generic kernel which gets its hardware information (FDT) from U-Boot.
Offline
Speaking about EFI, the question here is what it brings of new?
EFI would allow building an installer image once without having to care about the specialities of the hardware. That's what an U-Boot that is already installed on the machine (in on-board flash for example) would do. The installer image would just contain Grub and a generic kernel which gets its hardware information (FDT) from U-Boot.
Majority of the SBC boards doesn't even have a flash, and those who have, its blank..
So to flash it, you need first an operating system running on it, or very specialized hardware to flash uboot to it..
Majority of people still needs a sd card, as a way, to boot at least the installer, and this is already provided by Devuan.
Devuan has a generic Installer for armhf and also for arm64.
Devuan is using only 1 bootloader, since you cannot escape it( uboot )..
How do you see it as an improvement, loading above the bootloader, a second bootloader( GRUB )?
It doesn't change nothing, for the image point of view, and complicates the process,
In the end you gain nothing from it, only looses..
If EFI were able to provide the kernel with sufficient information, so that the kernel would be able to boot, without uboot,
Then would be a improvement, but since from the beginning you need uboot anyway, I fail to understand what you gain with EFI..
Remember that uboot is the one that objectively needs to be compiled for each board separately..
Best Regards,
tux
Offline
Afaik, there is already a generic aarch64 ISO that works fine and comes with GRUB already. It's the mini.iso that can be found here:
https://pkgmaster.devuan.org/devuan/dis … t/mini.iso
It works fine in QEMU so I assume it should also work with u-boot.
Personally, I like the idea of the OP. Sure, you need to flash a board-specific u-boot once into the SPI. But once you've done it, installing any EFI-compatible OS should be as easy as doing the same on x86_64.
Yet, I'm not sure if having u-boot is enough or if you won't need a 2nd stage bootloader such as TianoCore. But if it already works with u-boot, why not give it a try?
Last edited by kuleszdl (2021-02-28 17:32:49)
Offline
Devuan is using only 1 bootloader, since you cannot escape it( uboot )..
How do you see it as an improvement, loading above the bootloader, a second bootloader( GRUB )?
It doesn't change nothing, for the image point of view, and complicates the process,
In the end you gain nothing from it, only looses..
There are at least two massive improvements.
U-Boot can boot one kernel. Just one. There are no backups, fallbacks or any flavor of Plan B. If you try to build a modified kernel with even the slightest modification, U-Boot can be adjusted to boot that kernel and only that kernel. With devices in the embedded space having grown rather larger, customized kernels are no longer such a big deal, but I for one still rather like having easier recovery options. GRUB provides this by allowing you to select from multiple installed kernels. U-Boot and GRUB do get updates, but those are generally once every few years (distribution release/update) rather than every few months (Linux kernel security updates).
GRUB is also rather more functional for interesting setups. Notably GRUB's scripts are readily setup for booting interesting options. By interesting what I mean is GRUB can boot FreeBSD or Xen. Devices with hardware capable of running Xen are becoming more common (Raspberry PI 4B), so allowing for booting such setups out of the box is a Good Thing.
I note SuSE has chosen the route of U-Boot => GRUB => Linux kernel, so Devuan would not be alone if this approach was choosen. It is also noteworthy EBBR requires UEFI support so the next/current generation is converging on an interface suitable for GRUB as the common point, not U-Boot.
Offline