Things did not go so smooth today, therefor a bit angry and obnoxious which resulted in a rebellious mood.
Being in this mood stumbled across /etc/mock/rhelbeta-8-aarch64.cfg;
well well there is a public rhelbeta-8 repository.
this means you can build a rootfs…
with a decent kernel you should be able to boot and load it…
even better is a recent uboot to load /EFI/redhat/grubaa64.efi…
Quite a while a ago the guy who had (has?) a great deal in the aarch64 implementation at rhel stated he would do everything in his power to prevent people from booting device tree based devices.
Well they did not do that, I use the stock grub2-uefi aarch64 setup with a shim signed by Rethat, and my raspberry pi boots just fine.
A little bit more explanation, note to keep it simple and understandable i cut some corners so it’s not 100% accurate.
Except for the really first-boot stage everything is read from disk.
But the the (linux) kernel needs a system it understands with the most basic peripherals (such as ram, flash-disk, etc) up and running. This is something “Das U-boot” (the submarine) does on a lot of sbc’s before handing it over to the kernel / distro.
Moreover u-boot can mimic (or better can be) a Unified Extensible Firmware Interface. And this is what we use on aarch64. From the distro side of things after uboot the chain of events is exactly the same as on x86_64.
As said i was afraid some would try to cutoff this solution, but they did not
The subtitle of the project (the Universal Boot Loader) helps a lot to understand better what is.
For an uber-noob like me of linux and aarch64 architecture, seems me something like stage 1.5 of Grub Legacy, which only purpose was… launch stage 2.
Das U-Boot cover both stages (1 and 2) for bootload the OS starting from the inizialitation of the board…
(it’s quite old too… almost 20 years of history)
The amazing thing is you can configure uboot in both ways:
Load the kernel directly : no grub or something else in-between. you could think of this as uboot being the firmware (“bios”), mbr and bootloader in one.
“act as uefi bios”, load the efi boot-stub ( ie like stage 1.5 of Grub Legacy) which in turn load grub2 which loads the kernel.
Rhel designed aarch64 (arm 64 bit) to be the same as x86_64. Hence we try configure uboot to hand it over to the next stage in this similar fashion. you can think of this as uboot being the firmware (“bios” like AMI, Phoenix Technologies etc).
Being a n00b on ARM, but curious so I ask: Is it because of this ‘device tree’ thingy that ARM based systems use an image and not separate device drivers with config discovery like in the x86 world?
I ask this because of my interest in custom OS installs on smartphones (currently running LineageOS on a Sony Xperia XA2), but would love to install a custom OS on any phone, not only on a phone where an image is available for.
cannot explain the device tree much better as Wikipedia does. It’s the description of your hardware (btw not exclusive to arm).
I’ll guess you mean “as in the PC world” (as in former "IBM compatible PC)
That’s tuff. the take away of the above is the line between the hardware, the drivers and OS is not as sharp as in the “PC world” in other words you probably need a specialized kernel for your phone. And i gues that’s the developers of the custom-phone images do.