[PATCH 05/10] bootm: Do bootstage processing in bootm_final()

Heinrich Schuchardt xypron.glpk at gmx.de
Thu Jan 8 19:04:51 CET 2026


On 1/8/26 18:41, Simon Glass wrote:
> Hi Heinrich,
> 
> On Wed, 7 Jan 2026 at 12:14, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> Am 7. Januar 2026 20:02:39 MEZ schrieb Simon Glass <sjg at chromium.org>:
>>> Hi Heinrich,
>>>
>>> On Tue, 6 Jan 2026 at 20:58, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>>
>>>> Am 7. Januar 2026 01:31:22 MEZ schrieb Simon Glass <sjg at chromium.org>:
>>>>> From: Simon Glass <sjg at chromium.org>
>>>>>
>>>>> Mark kernel start before booting. If enabled, show a bootstage report.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>> Signed-off-by: Simon Glass <simon.glass at canonical.com>
>>>>> ---
>>>>>
>>>>> 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
>>



More information about the U-Boot mailing list