Re: 'fastboot boot' TPL

[Laszlo Ersek <lersek@redhat.com>]

On 02/28/18 09:19, Ard Biesheuvel wrote:
> On 28 February 2018 at 08:15, Michael Zimmermann
> <sigmaepsilon92@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?

- Change the type of the event "ReceiveEvent" from EVT_NOTIFY_SIGNAL to
zero (0)

- remove the DataReady() function

- continue passing "ReceiveEvent" to mTransport->Start()

- in the WaitForEvent() call near the end of FastbootAppEntryPoint(),
also wait for "ReceiveEvent"

- whenever "ReceiveEvent" fires, implement the same logic as seen
originally in DataReady(), but now near the end of FastbootAppEntryPoint().

The idea -- already used with "mFinishedEvent" BTW -- is that an event
can have type 0, which means it can be signaled and waited for without
ever queueing a notification function (at either signaling or waiting).
So mTransport should continue signaling ReceiveEvent whenever data is
ready. But, readiness should be observed in the "main loop", and the
data should be read, parsed and acted upon in that context as well, not
in a callback.

Thanks,
Laszlo