[dev] Opensource (multiboot) Bootloader: Efidroid (formerly Grub4android)


You, sir, are a gift from the sky. The thought of having GRUB on my Mi2S is a breath of oxygen, and the only thing that keeps me from inserting the phone into a Tokamak. As if having my recovery overwriten with that joke of MiRecovery with every boot wasn't bad enough, Xiaomi decided to keep me from installing a custom recovery at all. I really need a bootloader that doesn't decide on its own what to do with my terminal.

I don't want to bother you, but I wasn't able to understand where the prject is right now. Is g4a fully working right now? Is it unstable and experimental? Is it possible to install it only through complex procedures, or is GrubInstaller available?
The bootloader is not related to your recovery problems. Everytime you install a MIUI ROM all bootloaders, modem and recovery get overwritten.

G4A can protect itself(and any other partition) though thx to the live ramdisk patching technology.

G4A has come very far, but when I started to implement the Installer Application I realized that things are getting very nasty due to the need of intelligent config generation.
It's uncomfortable for users if they need to regenerate the configs everytime and u completely loose the ability to just insert a sdcard (or OTG in the far future) and boot the system. Instead u'd first have to boot up Android(which might not be installed yet) and regenerate the configs.

Obviously my first thought was sth. like "Let's add automatic config generation/system detection to GRUB". While that might have worked it still wasn't the perfect solution.
Also there still is the problem that I want the possibility to add amarullz GUI framework libaroma in future to provide complicated Bootloader GUI's with animations and stuff. That's completely impossible for GRUB due to the lack of threading support.

So, what to do? I already had experience with the UEFI interface because what I did to allow using one generic grub binary for all devices was to implement the UEFI API in Qualcomm's bootloader LK. That was a crazy (but very good) move by itself but if we're already using some form of UEFI why not using the real thing?.

Another thing I want to point out before continuing this talk is that G4A doesn't actually use QCOM's version of LK anymore because I completely rewrote their code and ported it to Travis Geiselbrecht's upstream version of LK which made some great development and makes the whole thing much faster. The downside of this is that we effectively loose support for all SoC's except those I've already ported and while in theory it's quite easy to port qcom's code my experience has shown me that there are many problems you have to fix before the code will boot successfully on your device.

So as you might know now IF you read my unusually big explanation, my new goal is to port UEFI. But how does it solve the SoC compatibility problem? well I'm not gonna port LK's linux style code to Intel UEFI's windows style code. That's for sure.
I'm loading LK as a lib(it actually is a little bit more complicated but that's not important right now) and just add wrapper drivers to UEFI.

NOW THE IMPORTANT PART: What does all this mean for G4A?
1) G4A is dead. EFIDroid is alive. You could call it a rename but I started completely from scratch and the codebase is totally different
https://github.com/efidroid
2) If everything goes well we'll be able to use original qcom bootloaders and make them expose their drivers to UEFI
3) the GRUBManager app will be much simpler for both developers and users because u can just install and manage ROM's without nasty config regeneration.
4) the project's progess? like 5%
- Build system: Done
- LK: can be booted and loads UEFI, but just supports the serial_port_write API atm
- UEFI: boots, can print debug messages to console, but fails at initializing the memory mapping
TODO?:
1) make UEFI boot to shell with all drivers fully working
2) add support for booting Android
3) add support for finding Multiboot installations
4) add a simple GUI

PS: This is some kind of giant information leak. Nobody but @linuxx knew about it till know :)
PS2: A nice side effect is that even if this is not the goal of EFIDroid, you still will be able to boot GRUB, because all GRUB needs is the UEFI API :)
 
Last edited:
Thanks for the clarification and for sharing with us all this precious informations! Actually, I did not mean the fact any custom bootloader gets overwriten with every boot. That is old story. With latest versions of MIUI 6, Xiaomi has apparently modified the bootloader so that any custom recoveries will not boot at all.

Sad to hear you have to practically trash all hard work done until now and start from scratch. Isn't there any way accessible to the average Android user to get GRUB on their already ported devices (I have a Mi2S), settling with no external storage, boot animations and such?
 
  • Like
Reactions: cbpbxecmecmbeh
Thanks for the clarification and for sharing with us all this precious informations! Actually, I did not mean the fact any custom bootloader gets overwriten with every boot. That is old story. With latest versions of MIUI 6, Xiaomi has apparently modified the bootloader so that any custom recoveries will not boot at all.

Sad to hear you have to practically trash all hard work done until now and start from scratch. Isn't there any way accessible to the average Android user to get GRUB on their already ported devices (I have a Mi2S), settling with no external storage, boot animations and such?

Well I don't have to trash all work. The multiboot init process still can be use. Also I got a lot of experience with bootloaders this way.
Unfortunately there's no fully working G4A code. Both LK and GRUB will successfully bot, GRUB will inject the multiboot stuff into the ramdisk and will boot Android. The multiboot part is what's currently incomplete.
 
  • Like
Reactions: MSephiroth
Hi M1cha,

What HisDudeness said: With latest versions of MIUI 6, Xiaomi has apparently modified the bootloader so that any custom recoveries will not boot at all. is there anything you can do about this??
AndroidFuchs tried but xiaomi/miui patched this workaround http://en.miui.com/thread-102413-1-1.html

Feel kinda betrayed by xiaomi/miui..


ps. great to hear about EFIDroid
 
Hi M1cha,

What HisDudeness said: With latest versions of MIUI 6, Xiaomi has apparently modified the bootloader so that any custom recoveries will not boot at all. is there anything you can do about this??
AndroidFuchs tried but xiaomi/miui patched this workaround http://en.miui.com/thread-102413-1-1.html

Feel kinda betrayed by xiaomi/miui..


ps. great to hear about EFIDroid
well afaik he just downgrades the bootloader. why this wouldn't work anymore?
 
Last edited:
  • Like
Reactions: M1cha
Not only you are working on a lot of titanic projects, you even find the time and patience to babysit us with our problems. I have no words to thank you, Michael. I'll try ASAP and let you know if it worked.
thx :)
It's hard to keep the balance between life and development because I tend to give up real life completely to work on a cool project.
the reason why the time between my updates got that long is that I need to catch up on many real life stuff like learning for university.
 
status update:

- Build system: Done
- LK: can be compiled as a library, used by UEFI
- UEFI: boots, console, MMC, Display working, can boot to UEFI shell or GRUB.

Next steps?:
- improve rendering speed (using NEON)
- improve MMU mappings and automatically import them from LK
- add support for booting Android
- add support for finding Multiboot installations
- create a better GUI
 

Attachments

  • my_photo-1.jpg
    my_photo-1.jpg
    60.3 KB · Views: 426
status update:

- Build system: Done
- LK: can be compiled as a library, used by UEFI
- UEFI: boots, console, MMC, Display working, can boot to UEFI shell or GRUB.

Next steps?:
- improve rendering speed (using NEON)
- improve MMU mappings and automatically import them from LK
- add support for booting Android
- add support for finding Multiboot installations
- create a better GUI
<3
 
  • Like
Reactions: MSephiroth
now, the bootmanager app works too :D
Seriously, who saw dat UI on a phone before? XD

Now I need to implement persistent storage so u can actually configure the whole thing and save some settings.
 

Attachments

  • my_photo-3.jpg
    my_photo-3.jpg
    49.2 KB · Views: 442
With this could be possible to put the system running just a GPS software? (Could be cool to turn the device exclusively a gps machine to center resources and save some power juice)
 
With this could be possible to put the system running just a GPS software? (Could be cool to turn the device exclusively a gps machine to center resources and save some power juice)
u don't need any bootloader(but the standard one) to do such things.
Everything is possibe but it's very complicated because on qcom devices u need to communicate with the modem which is done by closed source userspace binaries. Also the device probably would consume way more more than in Android because bootloaders don't have power management.