Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
Hi Daniel,
Gentle ping. Your feedback on this approach would be helpful.
On 07/02/2022 08:46, Jan Beulich wrote:
On 06.02.2022 20:28, Julien Grall wrote:
From: Julien Grall
Currently, the EFI stub will only query the console information and
get the GOP when using the configuration file.
However, GRUB is never providing the a configuration file. So the
EFI framebuffer will not be usable at least on Arm (support will
be added in a follow-up patch).
Move out the code outside of the configuration file section.
Take the opportunity to remove the variable 'size' which was
set but never used (interestingly GCC is only complaining if it is
initialization when declaring the variable).
With this change, GCC 8.3 will complain of argc potentially been
used unitiatlized. I suspect this is because the argc will
be iniitalized and used in a different if code-blocks. Yet they
are using the same check.
I'm inclined to suggest this wants to be a separate change, with its
own justification. You're not touching any use of argc here, after
all.
Signed-off-by: Julien Grall
It is not entirely clear to me why the GOP was only fetched when
the configuration file is used.
I have tested this on RPI4 and it seems to work. Any chance this
was done to workaround an x86 platform?
This was done so in the context of making the code work for Arm. See
commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
when booted from GRUB"), the description of which explicitly says
"Don't do EFI console or video configuration when booted by GRUB. The EFI boot
code does some console and video initialization to support native EFI boot
from
the EFI boot manager or EFI shell. This initlization should not be done when
booted using GRUB."
What you say now is effectively the opposite (and unlike back then
x86 is now able to use this code path as well, so needs considering
too). Cc-ing Daniel for possibly having a GrUB-side opinion.
Jan
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
EFI_LOADED_IMAGE *loaded_image;
EFI_STATUS status;
-unsigned int i, argc;
+/* Initialize argc to stop GCC complaining */
+unsigned int i, argc = 0;
CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-UINTN gop_mode = ~0;
+UINTN gop_mode = ~0, cols = 0, rows = 0;
+
EFI_SHIM_LOCK_PROTOCOL *shim_lock;
EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
union string section = { NULL }, name;
@@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
efi_arch_relocate_image(0);
+if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+ , ) == EFI_SUCCESS )
+efi_arch_console_init(cols, rows);
+
+gop = efi_get_gop();
+
if ( use_cfg_file )
{
EFI_FILE_HANDLE dir_handle;
-UINTN depth, cols, rows, size;
-
-size = cols = rows = depth = 0;
-
-if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
- , ) == EFI_SUCCESS )
-efi_arch_console_init(cols, rows);
-
-gop = efi_get_gop();
+UINTN depth = 0;
/* Get the file system interface. */
dir_handle = get_parent_handle(loaded_image, _name);
Cheers,
--
Julien Grall
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
On 12/02/2022 18:20, Elliott Mitchell wrote:
On Sat, Feb 12, 2022 at 01:10:52PM +, Julien Grall wrote:
On 12/02/2022 01:33, Elliott Mitchell wrote:
On Mon, Feb 07, 2022 at 06:52:57PM +, Julien Grall wrote:
On 07/02/2022 08:46, Jan Beulich wrote:
On 06.02.2022 20:28, Julien Grall wrote:
It is not entirely clear to me why the GOP was only fetched when
the configuration file is used.
I have tested this on RPI4 and it seems to work. Any chance this
was done to workaround an x86 platform?
This was done so in the context of making the code work for Arm. See
commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
when booted from GRUB"), the description of which explicitly says
"Don't do EFI console or video configuration when booted by GRUB. The EFI boot
code does some console and video initialization to support native EFI boot
from
the EFI boot manager or EFI shell. This initlization should not be done
when
booted using GRUB."
I read that and still couldn't figure out why this was done like that.
The most likely motivation was simply "Eww! ACPI/UEFI use gobs of
memory! Purge the abomination!"
Unfortunately ACPI/UEFI are large an complex due to trying to solve a
large and complex problem. ACPI/UEFI attempt to provide an OS agnostic
presentation of the hardware layout. Whereas device-trees are a common
*format* for presenting hardware to *an* OS (similar to how JSON is a
common format).
Due to the size and complexity, most developers have preferred the
simpler device-tree format even though that severely limits OS choice.
As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus > the
x86 world where Intel dragged everyone onto ACPI/UEFI.
One can see this in patches like Roman Shaposhnik's "Making full 2G of
memory available to Xen on HiKey" which simply tosses EFI into the
garbage bin as useless overhead.
I couldn't find a series with this name in my archives. By any chance,
are you referring to [1]?
The patch may have appeared under more than one title. The raw content
is publically visible at:
https://github.com/lf-edge/eve/blob/master/pkg/xen/arch/aarch64/0002-arm-efi-mem-detection.patch
The issue is few ARM projects are really trying to support enough
different devices for ACPI/UEFI to hit their forte. At which point
ACPI/UEFI get treated as worthless overhead.
Thanks! I wasn't aware of that patch.
You stated your patch was for 5.17-rc2. How much backporting would you
expect this patch to be viable for? (I'm unsure how much churn is
occuring in the relevant portions of Linux) The long-term branches of
Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could
apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely
viable, but 5.10 is risky and 5.4 is a very long shot.
I haven't looked at backports, so I don't know. But this is not a patch
I would consider to request for backport myself because IHMO this is
adding device support.
People who need this feature are likely to backport it themselves.
Well, anyone can ask backport. I am not planning to ask nor do the
backport work myselff. But feel free to send an e-mail to stable after
the Linux patch is merged.
Looking at the 5.10.92 source I've got handy, it appears reasonable. The
fuzz appears to have be a missed newline when I attempted to grab the
patch from the site you used.
You want test reports yet?
I need to do some respin. So I would say wait until the next version.
Cheers,
--
Julien Grall
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
On Sat, Feb 12, 2022 at 01:10:52PM +, Julien Grall wrote:
>
> On 12/02/2022 01:33, Elliott Mitchell wrote:
> > On Mon, Feb 07, 2022 at 06:52:57PM +, Julien Grall wrote:
> >> On 07/02/2022 08:46, Jan Beulich wrote:
> >>> On 06.02.2022 20:28, Julien Grall wrote:
>
> It is not entirely clear to me why the GOP was only fetched when
> the configuration file is used.
>
> I have tested this on RPI4 and it seems to work. Any chance this
> was done to workaround an x86 platform?
> >>>
> >>> This was done so in the context of making the code work for Arm. See
> >>> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
> >>> when booted from GRUB"), the description of which explicitly says
> >>>
> >>> "Don't do EFI console or video configuration when booted by GRUB. The
> >>> EFI boot
> >>>code does some console and video initialization to support native EFI
> >>> boot from
> >>>the EFI boot manager or EFI shell. This initlization should not be
> >>> done when
> >>>booted using GRUB."
> >>
> >> I read that and still couldn't figure out why this was done like that.
> >
> > The most likely motivation was simply "Eww! ACPI/UEFI use gobs of
> > memory! Purge the abomination!"
> >
> > Unfortunately ACPI/UEFI are large an complex due to trying to solve a
> > large and complex problem. ACPI/UEFI attempt to provide an OS agnostic
> > presentation of the hardware layout. Whereas device-trees are a common
> > *format* for presenting hardware to *an* OS (similar to how JSON is a
> > common format).
> >
> > Due to the size and complexity, most developers have preferred the
> > simpler device-tree format even though that severely limits OS choice.
> > As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus >
> > the x86 world where Intel dragged everyone onto ACPI/UEFI.
> >
> > One can see this in patches like Roman Shaposhnik's "Making full 2G of
> > memory available to Xen on HiKey" which simply tosses EFI into the
> > garbage bin as useless overhead.
>
> I couldn't find a series with this name in my archives. By any chance,
> are you referring to [1]?
The patch may have appeared under more than one title. The raw content
is publically visible at:
https://github.com/lf-edge/eve/blob/master/pkg/xen/arch/aarch64/0002-arm-efi-mem-detection.patch
The issue is few ARM projects are really trying to support enough
different devices for ACPI/UEFI to hit their forte. At which point
ACPI/UEFI get treated as worthless overhead.
> > You stated your patch was for 5.17-rc2. How much backporting would you
> > expect this patch to be viable for? (I'm unsure how much churn is
> > occuring in the relevant portions of Linux) The long-term branches of
> > Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could
> > apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely
> > viable, but 5.10 is risky and 5.4 is a very long shot.
> I haven't looked at backports, so I don't know. But this is not a patch
> I would consider to request for backport myself because IHMO this is
> adding device support.
People who need this feature are likely to backport it themselves.
Looking at the 5.10.92 source I've got handy, it appears reasonable. The
fuzz appears to have be a missed newline when I attempted to grab the
patch from the site you used.
You want test reports yet?
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
Hi,
On 12/02/2022 01:33, Elliott Mitchell wrote:
On Mon, Feb 07, 2022 at 06:52:57PM +, Julien Grall wrote:
On 07/02/2022 08:46, Jan Beulich wrote:
On 06.02.2022 20:28, Julien Grall wrote:
It is not entirely clear to me why the GOP was only fetched when
the configuration file is used.
I have tested this on RPI4 and it seems to work. Any chance this
was done to workaround an x86 platform?
This was done so in the context of making the code work for Arm. See
commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
when booted from GRUB"), the description of which explicitly says
"Don't do EFI console or video configuration when booted by GRUB. The EFI boot
code does some console and video initialization to support native EFI boot
from
the EFI boot manager or EFI shell. This initlization should not be done when
booted using GRUB."
I read that and still couldn't figure out why this was done like that.
The most likely motivation was simply "Eww! ACPI/UEFI use gobs of
memory! Purge the abomination!"
Unfortunately ACPI/UEFI are large an complex due to trying to solve a
large and complex problem. ACPI/UEFI attempt to provide an OS agnostic
presentation of the hardware layout. Whereas device-trees are a common
*format* for presenting hardware to *an* OS (similar to how JSON is a
common format).
Due to the size and complexity, most developers have preferred the
simpler device-tree format even though that severely limits OS choice.
As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus > the
x86 world where Intel dragged everyone onto ACPI/UEFI.
One can see this in patches like Roman Shaposhnik's "Making full 2G of
memory available to Xen on HiKey" which simply tosses EFI into the
garbage bin as useless overhead.
I couldn't find a series with this name in my archives. By any chance,
are you referring to [1]?
[...]
You stated your patch was for 5.17-rc2. How much backporting would you
expect this patch to be viable for? (I'm unsure how much churn is
occuring in the relevant portions of Linux) The long-term branches of
Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could
apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely
viable, but 5.10 is risky and 5.4 is a very long shot.
I haven't looked at backports, so I don't know. But this is not a patch
I would consider to request for backport myself because IHMO this is
adding device support.
Cheers,
[1]
https://lore.kernel.org/all/CAMmSBy8Zh00tebTvz=__gdv478++b-2t4248ynkh0w9dvgq...@mail.gmail.com/
--
Julien Grall
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
On Mon, Feb 07, 2022 at 06:52:57PM +, Julien Grall wrote:
> On 07/02/2022 08:46, Jan Beulich wrote:
> > On 06.02.2022 20:28, Julien Grall wrote:
> >>
> >> It is not entirely clear to me why the GOP was only fetched when
> >> the configuration file is used.
> >>
> >> I have tested this on RPI4 and it seems to work. Any chance this
> >> was done to workaround an x86 platform?
> >
> > This was done so in the context of making the code work for Arm. See
> > commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
> > when booted from GRUB"), the description of which explicitly says
> >
> > "Don't do EFI console or video configuration when booted by GRUB. The EFI
> > boot
> > code does some console and video initialization to support native EFI
> > boot from
> > the EFI boot manager or EFI shell. This initlization should not be done
> > when
> > booted using GRUB."
>
> I read that and still couldn't figure out why this was done like that.
The most likely motivation was simply "Eww! ACPI/UEFI use gobs of
memory! Purge the abomination!"
Unfortunately ACPI/UEFI are large an complex due to trying to solve a
large and complex problem. ACPI/UEFI attempt to provide an OS agnostic
presentation of the hardware layout. Whereas device-trees are a common
*format* for presenting hardware to *an* OS (similar to how JSON is a
common format).
Due to the size and complexity, most developers have preferred the
simpler device-tree format even though that severely limits OS choice.
As such, nuking ACPI/UEFI's presence is common in the ARM world. Versus
the x86 world where Intel dragged everyone onto ACPI/UEFI.
One can see this in patches like Roman Shaposhnik's "Making full 2G of
memory available to Xen on HiKey" which simply tosses EFI into the
garbage bin as useless overhead.
Yet the ARM world is now large enough to justify OS-agnostic solutions
such as ACPI/UEFI. The standards behind device-trees might be heading in
this direction, but they're way behind.
You stated your patch was for 5.17-rc2. How much backporting would you
expect this patch to be viable for? (I'm unsure how much churn is
occuring in the relevant portions of Linux) The long-term branches of
Linux include 5.4.179, 5.10.100 and 5.15.23. `patch` indicated it could
apply to 5.10.92 source with fuzz (hmm). This suggests 5.15 is likely
viable, but 5.10 is risky and 5.4 is a very long shot.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
On 07.02.2022 19:52, Julien Grall wrote:
> On 07/02/2022 08:46, Jan Beulich wrote:
>> On 06.02.2022 20:28, Julien Grall wrote:
>>> It is not entirely clear to me why the GOP was only fetched when
>>> the configuration file is used.
>>>
>>> I have tested this on RPI4 and it seems to work. Any chance this
>>> was done to workaround an x86 platform?
>>
>> This was done so in the context of making the code work for Arm. See
>> commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
>> when booted from GRUB"), the description of which explicitly says
>>
>> "Don't do EFI console or video configuration when booted by GRUB. The EFI
>> boot
>> code does some console and video initialization to support native EFI boot
>> from
>> the EFI boot manager or EFI shell. This initlization should not be done
>> when
>> booted using GRUB."
>
> I read that and still couldn't figure out why this was done like that.
>
>>
>> What you say now is effectively the opposite (and unlike back then
>> x86 is now able to use this code path as well, so needs considering
>> too). Cc-ing Daniel for possibly having a GrUB-side opinion.
>
> I am quite interested to know the answer. Linux is able to use the EFI
> framebuffer when booting via GRUB. So I am a bit puzzled why we are
> preventing this setup on dom0/Xen.
To be honest - same here.
Jan
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
Hi Jan,
On 07/02/2022 08:46, Jan Beulich wrote:
On 06.02.2022 20:28, Julien Grall wrote:
From: Julien Grall
Currently, the EFI stub will only query the console information and
get the GOP when using the configuration file.
However, GRUB is never providing the a configuration file. So the
EFI framebuffer will not be usable at least on Arm (support will
be added in a follow-up patch).
Move out the code outside of the configuration file section.
Take the opportunity to remove the variable 'size' which was
set but never used (interestingly GCC is only complaining if it is
initialization when declaring the variable).
With this change, GCC 8.3 will complain of argc potentially been
used unitiatlized. I suspect this is because the argc will
be iniitalized and used in a different if code-blocks. Yet they
are using the same check.
I'm inclined to suggest this wants to be a separate change, with its
own justification. You're not touching any use of argc here, after
all.
Ok. I will split it.
Signed-off-by: Julien Grall
It is not entirely clear to me why the GOP was only fetched when
the configuration file is used.
I have tested this on RPI4 and it seems to work. Any chance this
was done to workaround an x86 platform?
This was done so in the context of making the code work for Arm. See
commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
when booted from GRUB"), the description of which explicitly says
"Don't do EFI console or video configuration when booted by GRUB. The EFI boot
code does some console and video initialization to support native EFI boot
from
the EFI boot manager or EFI shell. This initlization should not be done when
booted using GRUB."
I read that and still couldn't figure out why this was done like that.
What you say now is effectively the opposite (and unlike back then
x86 is now able to use this code path as well, so needs considering
too). Cc-ing Daniel for possibly having a GrUB-side opinion.
I am quite interested to know the answer. Linux is able to use the EFI
framebuffer when booting via GRUB. So I am a bit puzzled why we are
preventing this setup on dom0/Xen.
Cheers,
--
Julien Grall
Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
On 06.02.2022 20:28, Julien Grall wrote:
> From: Julien Grall
>
> Currently, the EFI stub will only query the console information and
> get the GOP when using the configuration file.
>
> However, GRUB is never providing the a configuration file. So the
> EFI framebuffer will not be usable at least on Arm (support will
> be added in a follow-up patch).
>
> Move out the code outside of the configuration file section.
>
> Take the opportunity to remove the variable 'size' which was
> set but never used (interestingly GCC is only complaining if it is
> initialization when declaring the variable).
>
> With this change, GCC 8.3 will complain of argc potentially been
> used unitiatlized. I suspect this is because the argc will
> be iniitalized and used in a different if code-blocks. Yet they
> are using the same check.
I'm inclined to suggest this wants to be a separate change, with its
own justification. You're not touching any use of argc here, after
all.
> Signed-off-by: Julien Grall
>
>
>
> It is not entirely clear to me why the GOP was only fetched when
> the configuration file is used.
>
> I have tested this on RPI4 and it seems to work. Any chance this
> was done to workaround an x86 platform?
This was done so in the context of making the code work for Arm. See
commit c38cf865ec82 ("EFI: ignore EFI commandline, skip console setup
when booted from GRUB"), the description of which explicitly says
"Don't do EFI console or video configuration when booted by GRUB. The EFI boot
code does some console and video initialization to support native EFI boot from
the EFI boot manager or EFI shell. This initlization should not be done when
booted using GRUB."
What you say now is effectively the opposite (and unlike back then
x86 is now able to use this code path as well, so needs considering
too). Cc-ing Daniel for possibly having a GrUB-side opinion.
Jan
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
> static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
> EFI_LOADED_IMAGE *loaded_image;
> EFI_STATUS status;
> -unsigned int i, argc;
> +/* Initialize argc to stop GCC complaining */
> +unsigned int i, argc = 0;
> CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
> -UINTN gop_mode = ~0;
> +UINTN gop_mode = ~0, cols = 0, rows = 0;
> +
> EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
> union string section = { NULL }, name;
> @@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
>
> efi_arch_relocate_image(0);
>
> +if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> + , ) == EFI_SUCCESS )
> +efi_arch_console_init(cols, rows);
> +
> +gop = efi_get_gop();
> +
> if ( use_cfg_file )
> {
> EFI_FILE_HANDLE dir_handle;
> -UINTN depth, cols, rows, size;
> -
> -size = cols = rows = depth = 0;
> -
> -if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> - , ) == EFI_SUCCESS )
> -efi_arch_console_init(cols, rows);
> -
> -gop = efi_get_gop();
> +UINTN depth = 0;
>
> /* Get the file system interface. */
> dir_handle = get_parent_handle(loaded_image, _name);
[PATCH RFC 1/3] xen/efi: Always query the console information and get GOP
From: Julien Grall
Currently, the EFI stub will only query the console information and
get the GOP when using the configuration file.
However, GRUB is never providing the a configuration file. So the
EFI framebuffer will not be usable at least on Arm (support will
be added in a follow-up patch).
Move out the code outside of the configuration file section.
Take the opportunity to remove the variable 'size' which was
set but never used (interestingly GCC is only complaining if it is
initialization when declaring the variable).
With this change, GCC 8.3 will complain of argc potentially been
used unitiatlized. I suspect this is because the argc will
be iniitalized and used in a different if code-blocks. Yet they
are using the same check.
Signed-off-by: Julien Grall
It is not entirely clear to me why the GOP was only fetched when
the configuration file is used.
I have tested this on RPI4 and it seems to work. Any chance this
was done to workaround an x86 platform?
---
xen/common/efi/boot.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 12fd0844bd55..80e4e32623c4 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1129,9 +1129,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
EFI_LOADED_IMAGE *loaded_image;
EFI_STATUS status;
-unsigned int i, argc;
+/* Initialize argc to stop GCC complaining */
+unsigned int i, argc = 0;
CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-UINTN gop_mode = ~0;
+UINTN gop_mode = ~0, cols = 0, rows = 0;
+
EFI_SHIM_LOCK_PROTOCOL *shim_lock;
EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
union string section = { NULL }, name;
@@ -1219,18 +1221,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
efi_arch_relocate_image(0);
+if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+ , ) == EFI_SUCCESS )
+efi_arch_console_init(cols, rows);
+
+gop = efi_get_gop();
+
if ( use_cfg_file )
{
EFI_FILE_HANDLE dir_handle;
-UINTN depth, cols, rows, size;
-
-size = cols = rows = depth = 0;
-
-if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
- , ) == EFI_SUCCESS )
-efi_arch_console_init(cols, rows);
-
-gop = efi_get_gop();
+UINTN depth = 0;
/* Get the file system interface. */
dir_handle = get_parent_handle(loaded_image, _name);
--
2.32.0
