- May 29, 2011
- 1,747
- 297
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:
