<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/cmd/bootefi.c, branch v2022.01</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>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>
<entry>
<title>efi_loader: implement EFI_DT_FIXUP_PROTOCOL</title>
<updated>2021-01-13T01:38:01+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2020-12-13T09:30:24+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=94686f60a2b9fd87842f473a5cdca316668765c3'/>
<id>94686f60a2b9fd87842f473a5cdca316668765c3</id>
<content type='text'>
A boot manager like GRUB can use the protocol to

* apply U-Boot's fix-ups to the a device-tree
* let U-Boot make memory reservations according to the device-tree
* install the device-tree as a configuration table

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A boot manager like GRUB can use the protocol to

* apply U-Boot's fix-ups to the a device-tree
* let U-Boot make memory reservations according to the device-tree
* install the device-tree as a configuration table

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: setting boot device</title>
<updated>2021-01-13T01:38:00+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-01-12T11:46:24+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5f59518a7b1aef9ad3a91defa06cff82dd01cdc5'/>
<id>5f59518a7b1aef9ad3a91defa06cff82dd01cdc5</id>
<content type='text'>
Up to now the bootefi command used the last file loaded to determine the
boot partition. This has led to errors when the fdt had been loaded from
another partition after the EFI binary.

Before setting the boot device from a loaded file check if it is a PE-COFF
image or a FIT image.

For a PE-COFF image remember address and size, boot device and path.

For a FIT image remember boot device and path.

If the PE-COFF image is overwritten by loading another file, forget it.

Do not allow to start an image via bootefi which is not the last loaded
PE-COFF image.

Signed-off-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 the bootefi command used the last file loaded to determine the
boot partition. This has led to errors when the fdt had been loaded from
another partition after the EFI binary.

Before setting the boot device from a loaded file check if it is a PE-COFF
image or a FIT image.

For a PE-COFF image remember address and size, boot device and path.

For a FIT image remember boot device and path.

If the PE-COFF image is overwritten by loading another file, forget it.

Do not allow to start an image via bootefi which is not the last loaded
PE-COFF image.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: simplify running helloworld.efi</title>
<updated>2021-01-13T01:38:00+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-01-12T16:44:08+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=bb33c79e47e6ae4b538702b8f3d9a8ffc4b637ea'/>
<id>bb33c79e47e6ae4b538702b8f3d9a8ffc4b637ea</id>
<content type='text'>
Currently when executing 'bootefi hello' we copy helloworld.efi to the
address identified by environment variable loadaddr. This is unexected
behavior for a user. There is no need to copy helloworld.efi before
executing it after relocation.

Remove the copy action.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently when executing 'bootefi hello' we copy helloworld.efi to the
address identified by environment variable loadaddr. This is unexected
behavior for a user. There is no need to copy helloworld.efi before
executing it after relocation.

Remove the copy action.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: consider no-map property of reserved memory</title>
<updated>2020-10-06T05:43:56+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2020-08-27T10:52:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4cbb2930bd8c67f40f848528941930cf4c2a1841'/>
<id>4cbb2930bd8c67f40f848528941930cf4c2a1841</id>
<content type='text'>
The device tree may contain a /reserved-memory node. The no-map property
of the sub-nodes signals if the memory may be accessed by the UEFI payload
or not.

In the EBBR specification (https://github.com/arm-software/ebbr) the
modeling of the reserved memory has been clarified.

If a reserved memory node in the device tree has the no-map property map,
create a EfiReservedMemoryType memory map entry else use
EfiBootServicesData.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The device tree may contain a /reserved-memory node. The no-map property
of the sub-nodes signals if the memory may be accessed by the UEFI payload
or not.

In the EBBR specification (https://github.com/arm-software/ebbr) the
modeling of the reserved memory has been clarified.

If a reserved memory node in the device tree has the no-map property map,
create a EfiReservedMemoryType memory map entry else use
EfiBootServicesData.

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