[RFC PATCH 1/1] efi_loader: get rid of ad-hoc EFI subsystem init

[Heinrich Schuchardt]

On 1/20/23 20:19, Simon Glass wrote:
> Hi,
>
> On Fri, 20 Jan 2023 at 06:03, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> Am 20. Januar 2023 13:31:19 MEZ schrieb Ilias Apalodimas <ilias.apalodimas at linaro.org>:
>>> Up to now the EFI subsystem was left out of the main U-Boot init
>>> process.  This has led to various hacks over the years, with the most
>>> notable one being sprinkling around the efi init call to various places
>>> such as U-Boot commands, the early boot code etc.
>>>
>>> Since EFI has it's own Kconfig option and people can remove it, let's
>>> wire up the EFI init call on an event for EVT_MAIN_LOOP.
>>>
>>> This will also get rid of ad-hoc code in the main event loop, which was
>>> trying to initialize the subsystem early and perform capsule updates.
>>>
>>> TODO:
>>> - The efi_tcg protocol implicitly initializes the TPM, as a result
>>>   some of the tpm selftests will fail with the RFC.  If everyone
>>>   agrees that this is a good idea, I'll clean up the TPM hacks as well
>>> - We  still need to run capsule updates on the main_loop() code since
>>>   in some cases (e.g sandbox) we need preboot commands.
>>> - wider tests, I've only run QEMU for now
>>>
>>> Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
>>
>>
>> In case of efi_init_obj_list() failing we should still reach the U-Boot console but each of the EFI commands should abort early.
>>
>> Please, put the Kconfig related capsule change into a separate patch.
>>
>> Otherwise looks good to me.
>>
>
> I am OK with this change too.
>
> Two points from my side:
>
> 1. The main loop capsule update is (still) a mistake, unfortunately.
> It should be a command which is run on boot. For sandbox testing, that
> command should be run *without* rebooting. I am sure I asked for that

Capsule updates must run outside of any command as this is required by
the UEFI specification.

Capsule updates require a reboot and the sandbox must behave as a
regular system so that we can run the same tests on all systems.

> at the time but for various reasons it didn't happen. Please can you
> make that change also?
>
> 2. EFI should not be maintaining its own separate data structures, but
> should keep them attached to driver model. They should be created as
> needed, dynamically, not all at the start. Is anyone looking at this?
> I am happy to help suggest initial target for this refactoring.

We have started with such a link for block devices. Once those block
devices are really UEFI compliant we should refactor the other devices
currently supported by EFI sub-system:

UART, network, RNG, video, TPM.

Some initialization like setting up UEFI variables will not have any
equivalence in the driver model.

Best regards

Heinrich