Well since the fastboot implementation already is an application (and not a driver) all we need to do is to use WaitEvent instead of a notify callback.
Once that's fixed I'd add ASSERTs on the current tpl to the relevant API functions so you know immediately when you try to violate the spec. On Feb 28, 2018 9:19 AM, "Ard Biesheuvel" <ard.biesheu...@linaro.org> wrote: > On 28 February 2018 at 08:15, Michael Zimmermann > <sigmaepsilo...@gmail.com> wrote: > >> I agree. Did you run into any issues due to this? > > Surprisingly no. I was just trying to understand the fastboot > implementation > > before I use it on my platform > > and was surprised that this works at all. I can imagine that's because > this > > is supposed to load linux's efistub which probably doesn't do anything > but > > calling SetVirtualMemoryMap and ExitBootServices. > > The ARM/Linux EFI stub does quite a bit more than that, actually. It > uses the various memory allocation and protocol handling services, to > carve out an allocation for the kernel, initrd and device tree, and to > access the command line, the EFI_RNG_PROTOCOL (if available) and to > interrogate the protocol database for GOP instances. > > > I can imagine that more complex loaders like the one used for Windows > > wouldn't work this way. > > > > No, and this is indeed something that should be fixed. Any clue as to how? > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
