On 1/20/23 20:19, Simon Glass wrote:
Hi,
On Fri, 20 Jan 2023 at 06:03, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
Am 20. Januar 2023 13:31:19 MEZ schrieb Ilias Apalodimas
<ilias.apalodi...@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.apalodi...@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
