Jan,
Are you trying to catch the messages from a screen, or are they
overwritten on a UART by the succeeding EFI app?
Yes, in my case, cleared/overwritten by the next EFI app.
The problem is that BG_ENVDATA is fully packed and has no extension
space (yeah...).
Another direction could be to make this a configuration time option,
but that would get in the way of being able to turn on this behaviour
in a deployed system.
Hmm ... what do you think about leveraging the user variable space
by reserving some namespace (eg names starting with "ebg_") ?
https://github.com/siemens/efibootguard/blob/master/docs/API.md#example-on-user-variable-usage
For example:
ebg_env_set(&e, "ebg_start_delay_ms", "3000");
Earl
On 2024-01-14 23:37, Jan Kiszka wrote:
On 15.01.24 00:20, 'Earl Chew' via EFI Boot Guard wrote:
While debugging an issue, it was helpful to have a short delay before
the StartImage() handoff in order to read/capture the efibootguard
messages.
Are you trying to catch the messages from a screen, or are they
overwritten on a UART by the succeeding EFI app?
For now, I used a 3 second BS->Stall() before invoking StartImage().
While this seems useful and unobtrusive enough to me, upstream users are
probably used to the existing behaviour.
What does the team think about another environment key
(watchdog_timeout_sec vs start_delay_sec) to achieve this?
The problem is that BG_ENVDATA is fully packed and has no extension
space (yeah...). We ran into that issue before, and the long-term plan
is to have a new configuration format, plus a clear migration path.
Short-term, not much is possible without breaking existing deployments.
Jan
--
You received this message because you are subscribed to the Google Groups "EFI Boot
Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to efibootguard-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/4e7dea5d-3ebe-425f-827b-375c564de18a%40yahoo.com.
