EFI payload / application support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 9 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 9 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/9] EFI payload / application support
Quoted 13 lines · Leif Lindholm
Quoted 12 lines · Alexander Graf
Quoted 12 lines
Quoted 1 line
This patch set is the result of pursuing this endeavor.
Thanks, this is a very cool thing.
I meant to reply sooner, but Christmas got in the way.Quoted 6 lines
- I am successfully able to run grub2 and Linux EFI binaries with this code.
- When enabled, the resulting U-Boot binary only grows by ~10kb, so it's very light weight.
- It works on 32bit ARM and AArch64.
- All storage devices are directly accessible
- No runtime services (all calls return unimplemented)
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Yeah, this is a bit of a pain point. The time services, virtual memory services and reset being the key ones.
I guess reset should be pretty well doable. What are virtual memory services? The bits that translate RTS code to run in virtual address space somewhere else?
Yup.
Can you point me to code that uses the time services?
Quoted 44 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
- No EFI variables
This would obviously (from my point of view) be desirable, but at least initially, we can do most things without persistent variables.
Quoted 8 lines
Doing EFI variables before exiting boot services is easy - we could even just map U-Boot variables to EFI variables. That could come in handy for cases where you want U-Boot to tell you which board you're on so you can refer to different dtb files in your grub.cfg (if you need to override the dtb).
Making them persistent is another difficult question - U-Boot usually splits "modify variable" from "store variable pool to nvram".
Indeed.
UEFI might as well, but in more convoluted ways.Quoted 2 lines
And the hardest part would obviously be to make all of this work while Linux is running ;). I'd definitely prefer to defer that bit to later.
Of course.
And again - depending on ambition levels, implementing a version of efibootmgr that ended up simply tweaking a
/boot/uEnv.txt(or similar) if U-Boot boot environment was detected would be entirely achievable.Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Of course, there are still a few things one could do on top:
- Implement removable media booting (search for /efi/boot/boota{a64,rm}.efi)
Yeah, that would be top of my wishlist.
That should be pretty simple to do - maybe we can even get away without any C code for it.
Should be possible.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
- Improve disk media detection (don't scan, use what information we have)
- Add EFI variable support using NVRAM
- Add GFX support
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
GFX support was actually never implemented for U-Boot GRUB, so from this p.o.v. it is not a shortcoming over the existing impementation.
Heh ;). My goal here really is to make U-Boot based systems be en par with TianoCore based ones in terms of usability.
Sure. Just setting the nearer goal post of "where can we replace U-Boot API in GRUB".
I am not aware of anyone using the U-Boot API for grub these days, so I'm not sure it's an incredibly useful goal. The main pain point distros seem to have is to make something that "just works" on all systems out there. Moving into that direction should be our ultimate goal.
Alex