On 1/8/26 18:41, Simon Glass wrote:
Hi Heinrich,
On Wed, 7 Jan 2026 at 12:14, Heinrich Schuchardt <[email protected]> wrote:
Am 7. Januar 2026 20:02:39 MEZ schrieb Simon Glass <[email protected]>:
Hi Heinrich,
On Tue, 6 Jan 2026 at 20:58, Heinrich Schuchardt <[email protected]> wrote:
Am 7. Januar 2026 01:31:22 MEZ schrieb Simon Glass <[email protected]>:
From: Simon Glass <[email protected]>
Mark kernel start before booting. If enabled, show a bootstage report.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
---
boot/bootm_final.c | 6 ++++++
test/boot/bootflow.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/boot/bootm_final.c b/boot/bootm_final.c
index 71661334e11..dd7cac55f1e 100644
--- a/boot/bootm_final.c
+++ b/boot/bootm_final.c
@@ -6,11 +6,17 @@
*/
#include <bootm.h>
+#include <bootstage.h>
#include <dm/root.h>
void bootm_final(enum bootm_final_t flags)
{
printf("\nStarting kernel ...\n\n");
This noisy message makes no sense for EFI booting. The kernel in not started in
ExitBootServices().
Can you explain that a bit more? I believe that's exactly when the
kernel starts.
Operating systems like Ubuntu tend to boot the kernel with argument "quiet" for
aesthetic reasons. We should not disrupt this.
When I boot (with this patch) I see these messages on the serial console:
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part E Name Filename
--- ----------- ------ -------- ---- - ------------------------
----------------
Scanning global bootmeth 'efi_mgr':
0 efi_mgr ready (none) 0 <NULL>
** Booting bootflow '<NULL>' with efi_mgr
try_load_entry() Booting: Label: Ubuntu Device path:
/HD(1,GPT,eccaac1c-b634-441b-a788-ab0f959111af,0x800,0x165800)/\EFI\ubuntu\shimx64.efi
Here GRUB is running. If you don't see output, then because purposefully it has
been quieted.
OK, so there is no problem, right?
To make it clear:
Once the EFI application is started firmware like U-Boot or EDK II
should not write any message to the video buffer or to the serial console.
Best regards
Heinrich
Starting kernel ...
ExitBootServices is called in the middle of the Linux kernel EFI stub and not
when entering the kernel.
Oh I see. To my mind the kernel EFI stub is a bit like a bootloader
tacked onto the front of Linux. Linux doesn't properly start until it
has control of the machine and actually starts its init.
So we definitely want to get bootstage output (for example) covering
that period, otherwise there is a significant uncounted time between
the EFI app starting and Linux starting.
Regards,
Simon
Best regards
Heinrich
<<<
So it is not silent today. The last line is the new one. Every other
boot method writes this line.
However, the video display is silent once grub has finished and I just
noticed that this patch draws some pixels on the display, as if the
EFI display is set to a different mode from what U-Boot expects. I
suppose this is understandable, as grub has run by then and has
probably changed the mode.
So I wonder what would be best here. We don't support dynamic video
sizing right now and I don't feel the urge to implement it just for
this. Perhaps with EFI we could disable the vidconsole when
exit-boot-services is called, on the basis that we cannot deal with
whatever has happened to the display in the interim?
Regards,
Simon
Best regards
Heinrich
+ bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, "start_kernel");
+
+ if (IS_ENABLED(CONFIG_BOOTSTAGE_REPORT))
+ bootstage_report();
+
dm_remove_devices_active();
}
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index a56435d053f..80adc074070 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -1381,7 +1381,7 @@ static int bootflow_efi(struct unit_test_state *uts)
/* TODO: Why the \r ? */
ut_assert_nextline("U-Boot test app for EFI_LOADER\r");
- ut_assert_nextline("Exiting test app");
+ ut_assert_skip_to_line("Exiting test app");
ut_assert_nextline("Boot failed (err=-14)");
ut_assert_console_end();
Regards,
Simon
