After discussing with Debian developers at a conference they told me that GRUB could be added this way:

u-boot would be built to provide compatibility with UEFI.

GRUB would also be built for ARM UEFI and then be chainloaded by u-boot.

On Mon, 09 Dec 2019 22:38:47 +0000 labs@parabola.nu wrote:

This can be improved to be even more by using grub

even more ... what? - more user-friendly, more capable, ... -
what is the problem that would this solve, or which abilities
would be gained?

not that i intend a counter argument - if you believe its a good
idea, then i am inclined to concur - just trying to understand
it more

People are used to GRUB on x86, so the idea is to minimize the difference between ARM and x86 so it looks more familiar to people.

ok i guess what i really wondering is because the title is "add back GRUB"; but why was it removed in the first place - was it broken

it would be an improvement, if there were a generally usable bootloader for ARM, or some combination of them - the ARM tarballs are intended to make installation as simple as possible; but the ones we publish now have no bootloader - that is an extra step, which ideally would be avoided by an automated solution

Something worth considering is that I've not seen a ARM board that defaults to grub.
Always uboot or something proprietary. So by re-introducing grub aren't we just
teaching people to do things in a non-standard way?

Learning the ins and outs of uboot was one of the better parts of getting ARM devices going. But then I'm not the "average User"

Anyways, Just something to mull.

I'm a Parabola user on armv7 (Chromebook C201). Just throwing my 2 cents in here, but I'm not a huge fan of the u-boot bootloader that comes shipped with the Chromebook. It seems to me it is built very specifically for the Chromebook device, which I guess is not necessarily a bad thing. However, a couple of drawbacks come to mind:

1. Firstly, as GNUtoo mentioned, most Linux users are used to GRUB to some extent. I myself have spent some time learning how to use GRUB; mucking about with grub.cfg files occasionally to customize boot menus; sometimes falling back to the GRUB command line to fix issues. The fact that the Chromebook uses a different bootloader is something else new to learn - if it was using the more familiar GRUB, like everything else, it might help encourage adoption of GNU/Linux on ARM devices.

2. Secondly, u-boot seems to be very basic - for instance, it doesn't seem to be possible to do many of the things I mentioned above in point 1. You press CTL-U and it boots you in to the highest 'priority' installation - bam! I am not aware of any config file for it (although, maybe there is one somewhere) and it doesn't provide a nice menu, like GRUB does, where you can choose what system you want to boot up. Now, perhaps many ARM Linux users don't need/want to be messing about with grub.cfg; however, on my Chromebook I have several Linux system installed on different partitions. I have Parabola on one, but I also have an installation of ALARM on another (which I use as a fallback in case Parabola breaks). With u-boot, if I want to change which system I boot into, I have to log in to one of them as root; change the CGPT partition settings; and then reboot, which is a bit of a pain. It would be great if there was a nice GRUB menu that would allow me to easily select which system to boot up.

In summary, u-boot seems to be very simple and easy to use, which might suit users who just want a simple system. However, that simplicity makes it harder for those that want to do something more complex.

Another thing to mention: I believe Libreboot is available for the Chromebook C201 and can be built to include GRUB as a payload. So, if GRUB were built for ARM and added to LB as a payload, would it even need UEFI services? Libreboot isn't based on EFI (as I understand it).

bill-auger wrote:

ok i guess what i really wondering is because the title is "add back GRUB"; but why was it removed in the first place - was it broken

My understanding is that GRUB wasn't so much 'taken away' as not ported to ARM in the first place. Presumably, this is because many of the devices already had free software bootloaders that could be used (i.e. u-boot), so there hasn't been much drive to make the effort to port GRUB.

I didn't look into how to implement it yet in practice in u-boot, but there is probably an easy way to make sure that users can choose between both.

As for how it was done before, as I understand it, GRUB was tied with uboot in a very different way, which had its issues.

For instance the load address was hardcoded in grub, so it didn't work by default with all System on a chip without needing to change the address at compilation time with a patch.

As for Libreboot, there is now some support for arm-coreboot in GRUB however I didn't test it so I don't know in what shape it is.

i just wanted to relate this ticket to the ARM install guide,
which is very spotty in some areas, especially boot-loaders -
the parabola ARM tarball does not include a boot-loader; so this
is an especially important topic for the install guide

some wiki items that need fixing:

• the note that some of the uboot4grub packages are in
  [libre-testing]
• the note regarding GRUB, that "Parabola hackers are
  investigating using this."
• the prominent warning at the top of the page: "Warning: Theses
  new instructions are experimental and have not been tested yet.
  Remove this warning and/or contact Parabola any parabola
  contributor to remove this warning if they worked for you."

that warning is unprofessional - i would like to see it
removed ASAP - the person who wrote that, should have taken the
time to verify the install instructions themselves, or asked
someone with an ARM board to do it, rather than publishing such a
tacky warning - that is akin to announcing that parabola
developers can not verify that the system actually works on any
ARM hardware - if that were true, then we should not be
publishing an ARM port - quality control is not something to
defer onto users of the system, as guinea-pigs - at least one of
us needs to test these systems routinely on real hardware