<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/cmd/bootefi.c, branch v2022.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>efi_loader: Ignore DT when ACPI is on</title>
<updated>2022-03-20T10:03:06+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@csgraf.de</email>
</author>
<published>2022-02-27T12:18:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0832dd2900f3ec7bf2ae12866138fc0fd9970168'/>
<id>0832dd2900f3ec7bf2ae12866138fc0fd9970168</id>
<content type='text'>
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.

To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.

Signed-off-by: Alexander Graf &lt;agraf@csgraf.de&gt;
Reviewed-by: Mark Kettenis &lt;kettenis@openbsd.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.

To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.

Signed-off-by: Alexander Graf &lt;agraf@csgraf.de&gt;
Reviewed-by: Mark Kettenis &lt;kettenis@openbsd.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: update the timing of enabling and disabling EFI watchdog</title>
<updated>2022-02-26T06:37:01+00:00</updated>
<author>
<name>Masahisa Kojima</name>
<email>masahisa.kojima@linaro.org</email>
</author>
<published>2022-02-22T00:58:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3fa9ed9ae3b30dd6e7f5e887c76d183ad72a44a2'/>
<id>3fa9ed9ae3b30dd6e7f5e887c76d183ad72a44a2</id>
<content type='text'>
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima &lt;masahisa.kojima@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Add debugging to efi_set_bootdev()</title>
<updated>2022-02-05T19:20:01+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2022-01-29T21:58:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d837cb1e3b6bf6a3d77f058b90ea937935fc2c8f'/>
<id>d837cb1e3b6bf6a3d77f058b90ea937935fc2c8f</id>
<content type='text'>
The operation of this function can be confusing. Add some debugging so
we can see what it is doing and when it is called.

Also drop the preprocessor usage.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The operation of this function can be confusing. Add some debugging so
we can see what it is doing and when it is called.

Also drop the preprocessor usage.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Get rid of kaslr-seed if EFI_RNG_PROTOCOL is installed</title>
<updated>2022-01-15T09:57:22+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2022-01-03T12:07:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a2f1482fc0e6c5dbdbafecd360d168f9c12fc529'/>
<id>a2f1482fc0e6c5dbdbafecd360d168f9c12fc529</id>
<content type='text'>
U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
node. That would be problematic in case we want to measure the DTB we
install in the configuration table, since it would change across reboots.

The Linux kernel EFI-stub completely ignores it and only relies on
EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
of the physical placement of the kernel). In fact it (blindly) overwrites
the existing seed if the protocol is installed. However it still uses it
for randomizing it's virtual placement.
So let's get rid of it in the presence of the RNG protocol.

It's worth noting that TPMs also provide an RNG.  So if we tweak our
EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
is present the 'kaslr-seed' property will always be removed, allowing
us to reliably measure our DTB.

Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Mark Kettenis &lt;kettenis@openbsd.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
node. That would be problematic in case we want to measure the DTB we
install in the configuration table, since it would change across reboots.

The Linux kernel EFI-stub completely ignores it and only relies on
EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
of the physical placement of the kernel). In fact it (blindly) overwrites
the existing seed if the protocol is installed. However it still uses it
for randomizing it's virtual placement.
So let's get rid of it in the presence of the RNG protocol.

It's worth noting that TPMs also provide an RNG.  So if we tweak our
EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
is present the 'kaslr-seed' property will always be removed, allowing
us to reliably measure our DTB.

Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Mark Kettenis &lt;kettenis@openbsd.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Convert simple_strtoul() with hex to hextoul()</title>
<updated>2021-08-02T17:32:14+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2021-07-24T15:03:29+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7e5f460ec457fe310156e399198a41eb0ce1e98c'/>
<id>7e5f460ec457fe310156e399198a41eb0ce1e98c</id>
<content type='text'>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Replace config option for initrd loading</title>
<updated>2021-03-25T19:14:26+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2021-03-17T19:55:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=53f6a5aa86267a59ea9d45c89405e42002410e37'/>
<id>53f6a5aa86267a59ea9d45c89405e42002410e37</id>
<content type='text'>
Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not installed.

This creates a problem for EFI installers, since they won't be able to
load their own initrd and continue the installation. It also makes the
feature hard to use, since we can either have a single initrd or we have
to recompile u-boot if the filename changes.

So let's introduce a different logic that will decouple the initrd
path from the config option we currently have.
When defining a UEFI BootXXXX we can use the filepathlist and store
a file path pointing to our initrd. Specifically the EFI spec describes:

"The first element of the array is a device path that describes the device
and location of the Image for this load option. Other device paths may
optionally exist in the FilePathList, but their usage is OSV specific"

When the EFI application is launched through the bootmgr, we'll try to
interpret the extra device path. If that points to a file that exists on
our disk, we'll now install the load_file2 and the efi-stub will be able
to use it.

This opens up another path using U-Boot and defines a new boot flow.
A user will be able to control the kernel/initrd pairs without explicit
cmdline args or GRUB.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not installed.

This creates a problem for EFI installers, since they won't be able to
load their own initrd and continue the installation. It also makes the
feature hard to use, since we can either have a single initrd or we have
to recompile u-boot if the filename changes.

So let's introduce a different logic that will decouple the initrd
path from the config option we currently have.
When defining a UEFI BootXXXX we can use the filepathlist and store
a file path pointing to our initrd. Specifically the EFI spec describes:

"The first element of the array is a device path that describes the device
and location of the Image for this load option. Other device paths may
optionally exist in the FilePathList, but their usage is OSV specific"

When the EFI application is launched through the bootmgr, we'll try to
interpret the extra device path. If that points to a file that exists on
our disk, we'll now install the load_file2 and the efi-stub will be able
to use it.

This opens up another path using U-Boot and defines a new boot flow.
A user will be able to control the kernel/initrd pairs without explicit
cmdline args or GRUB.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>image: Adjust the workings of fit_check_format()</title>
<updated>2021-02-16T03:31:52+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2021-02-16T00:08:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c5819701a3de61e2ba2ef7ad0b616565b32305e5'/>
<id>c5819701a3de61e2ba2ef7ad0b616565b32305e5</id>
<content type='text'>
At present this function does not accept a size for the FIT. This means
that it must be read from the FIT itself, introducing potential security
risk. Update the function to include a size parameter, which can be
invalid, in which case fit_check_format() calculates it.

For now no callers pass the size, but this can be updated later.

Also adjust the return value to an error code so that all the different
types of problems can be distinguished by the user.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reported-by: Bruce Monroe &lt;bruce.monroe@intel.com&gt;
Reported-by: Arie Haenel &lt;arie.haenel@intel.com&gt;
Reported-by: Julien Lenoir &lt;julien.lenoir@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At present this function does not accept a size for the FIT. This means
that it must be read from the FIT itself, introducing potential security
risk. Update the function to include a size parameter, which can be
invalid, in which case fit_check_format() calculates it.

For now no callers pass the size, but this can be updated later.

Also adjust the return value to an error code so that all the different
types of problems can be distinguished by the user.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reported-by: Bruce Monroe &lt;bruce.monroe@intel.com&gt;
Reported-by: Arie Haenel &lt;arie.haenel@intel.com&gt;
Reported-by: Julien Lenoir &lt;julien.lenoir@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>common: Drop asm/global_data.h from common header</title>
<updated>2021-02-02T20:33:42+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2020-10-31T03:38:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=401d1c4f5d2d29c4bc4beaec95402ca23eb63295'/>
<id>401d1c4f5d2d29c4bc4beaec95402ca23eb63295</id>
<content type='text'>
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include &lt;asm/global_data.h&gt; at all, so
remove that include.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include &lt;asm/global_data.h&gt; at all, so
remove that include.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: switch to non-secure mode later</title>
<updated>2021-01-29T19:22:40+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-01-24T14:34:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=82d01f04facef1276cede067efd02d2a731ffe83'/>
<id>82d01f04facef1276cede067efd02d2a731ffe83</id>
<content type='text'>
Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec &lt;jernej.skrabec@gmail.com&gt;
Reported by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec &lt;jernej.skrabec@gmail.com&gt;
Reported by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: make the UEFI boot manager configurable</title>
<updated>2021-01-20T07:09:34+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-01-15T18:02:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ff2f532fadd8f5238cc1ac2ae4ab075703bcc313'/>
<id>ff2f532fadd8f5238cc1ac2ae4ab075703bcc313</id>
<content type='text'>
Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.

Provide a configuration option to make the boot manager available.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.

Provide a configuration option to make the boot manager available.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
