[RFC PATCH 1/1] efi_loader: get rid of ad-hoc EFI subsystem init
xypron.glpk at gmx.de
Fri Jan 20 21:31:10 CET 2023
On 1/20/23 20:19, Simon Glass wrote:
> 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.
>>> - 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.
More information about the U-Boot