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ā¦
And look what my raspberry PI3+ is booting:
so good news or badā¦beware of the ARM newbee I am 
Iās say this is great news! works like a charm 
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.
Manny single board computers like the arm boards as the raspbery PI do not have a BIOS most certainly not a Unified Extensible Firmware Interface (uefi).
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)
Well you got it about right
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.
-or-
ā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.
Posted this link before a while ago (can not find it).
The developer of the uboot-uefi can explain it the best: