zaval wrote:
bzt, try to create a Load Option for your loader and put it the first. Interestingly, OVMF images come preconfigured to have a Load Option for the UEFI shell, and since, as I've already pointed out, \efi\boot\bootXXXX.efi is optional for non-removable storages, it might well be not tried at all esp. given a Load Option is set.
Thanks for the tip, but \efi\boot\bootXXXX.efi is configured by default all right.
zaval wrote:
That delay, you describe might be some stupid waiting because you didn't provide Load Options, because for me, after Tianocore logo disappears, the UEFI shell does appear instantly or my Loader, - what is set first.
As I've said, I have no problem after the TianoCore logo disappears. My loader is pretty fast. The long delay happens before that (most of it before the TianoCore logo shown).
zaval wrote:
UEFI isn't monstrosity per se, EDK2 may be, but the standard itself is not.
Oh yes, it is. One of the worst "standards" ever. From the overall concept to the simple things. For example what "Number of partitions" mean in GPT? It is not well-defined: some interpret it as the number of active partitions, while for others it is the number of maximum usable partitions... Sadly the UEFI spec suggests both.
Then the big picture: most of the protocols are totally, completely useless after ExitBootServices. Now what kind of firmware is that, which does not provide services to the OS? UEFI should be called "Big Bloated Boot Environment" (TM), because it is definitely not usable as a "Firmware Interface" for the OS.
zaval wrote:
PI really has a lot of overdesigned stuff, but UEFI is slim. and extensible.
No, it isn't. OVMF.fd is at least a Megabyte (!!!) and in run-time requires several Megabytes of RAM, I wouldn't call that "slim". BIOS, on the other hand, with it's 128K size and minimal (ca. 64k) run-time RAM requirement, now that's what slim is!
zaval wrote:
You don't have to implement all the protocols, and oppositely - you can devise your own. The core is minimalistic and clear.
The
core alone is completely useless. There's nothing minimalistic and clear about the must-have bytecode interpreter for example. There's no standard interface to load a disk sector by default, and there's no standard interface to switch video modes for example. Both are defined as "optional", and need LocateProtocol, which might fail (even though the video driver is clearly a requirement for ConOut, and you cannot load anything (not even the loader) without a disk driver). I really would like to see a bootloader that's capable of booting an OS using only the UEFI core (without any LocateProtocol or OpenProtocol calls)...
What's the point of being "extensible" if many protocols (like BLOCKIO, SIMPLE_FILE, GOP etc.) must be implemented anyway because you simply can't load an OS without them? And what's the purpose of all the other "extensible" optional protocols, that no boot loader ever use, and which are inaccessible after ExitBootServices anyway?
Cheers,
bzt