On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote: > >> 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. > > > >> - 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) > > > > 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. > > > >> - 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. > > 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. > 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. > >> 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. > > > >> - Improve disk media detection (don't scan, use what information we have) > >> - Add EFI variable support using NVRAM > >> - Add GFX support > > > > 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". > > > >> - Make EFI Shell work ;) > > > > - Network device support. > > Oh, good point. I forgot about that one. > > > I also spotted a couple of minor things while playing around (things > > like image exit being missing), but these will be easy to flush out. > > Awesome, looking forward to the review! :) > > Thanks a lot for taking the time to look at this patch set. Sure, this is a very useful thing. Even at the most cynical possible position (which isn't where I am), this means additional interface testing using a completely separate codebase. / Leif _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot