<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/cmd/bootefi.c, branch v2016.05</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: Pass fdt address directly to bootefi cmd</title>
<updated>2016-04-18T21:11:49+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-14T14:07:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1c39809b92c217877e160ee91a82743c9d4f3ed1'/>
<id>1c39809b92c217877e160ee91a82743c9d4f3ed1</id>
<content type='text'>
The bootefi cmd today fetches its device tree pointer from either the
location appointed by "fdt addr" with a fallback to the U-Boot control
fdt.

This integration is unusual for U-Boot and diverges from the way we
usually handle parameters to boot commands. So let's pass the fdt
directly into the bootefi command instead and move the control fdt
logic into the distro boot script.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Acked-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Reviewed-by: Andreas Färber &lt;afaerber@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bootefi cmd today fetches its device tree pointer from either the
location appointed by "fdt addr" with a fallback to the U-Boot control
fdt.

This integration is unusual for U-Boot and diverges from the way we
usually handle parameters to boot commands. So let's pass the fdt
directly into the bootefi command instead and move the control fdt
logic into the distro boot script.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Acked-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Reviewed-by: Andreas Färber &lt;afaerber@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Put fdt into convenient location</title>
<updated>2016-04-18T21:11:40+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-11T21:51:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ad0c1a3d2cea03011091b07e9e066bf261d1556e'/>
<id>ad0c1a3d2cea03011091b07e9e066bf261d1556e</id>
<content type='text'>
The uEFI spec doesn't dictate where the device tree should live at, but
legacy 32bit ARM grub2 has some assumptions that it may stay at its place
when it's already loaded by the firmware.

So let's put it somewhere where Linux that comes after would happily find
it - around the recommended 128MB line.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Andreas Färber &lt;afaerber@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The uEFI spec doesn't dictate where the device tree should live at, but
legacy 32bit ARM grub2 has some assumptions that it may stay at its place
when it's already loaded by the firmware.

So let's put it somewhere where Linux that comes after would happily find
it - around the recommended 128MB line.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Andreas Färber &lt;afaerber@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Use system fdt as fallback</title>
<updated>2016-04-18T21:11:38+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-11T14:55:26+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0d9d501f359d82c19fc1d5a800888feadc82c1fe'/>
<id>0d9d501f359d82c19fc1d5a800888feadc82c1fe</id>
<content type='text'>
When the user did not pass any device tree or the boot script
didn't find any, let's use the system device tree as last resort
to get something the payload (Linux) may understand.

This means that on systems that use the same device tree for U-Boot
and Linux we can just share it and there's no need to manually provide
a device tree in the target image.

While at it, also copy and pad the device tree by 64kb to give us
space for modifications.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Andreas Färber &lt;afaerber@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the user did not pass any device tree or the boot script
didn't find any, let's use the system device tree as last resort
to get something the payload (Linux) may understand.

This means that on systems that use the same device tree for U-Boot
and Linux we can just share it and there's no need to manually provide
a device tree in the target image.

While at it, also copy and pad the device tree by 64kb to give us
space for modifications.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Andreas Färber &lt;afaerber@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Increase path string to 32 characters</title>
<updated>2016-04-18T21:11:37+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-11T14:16:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ecbe1a07c507d37aeb5f0f9ce1c4cc20c70fec64'/>
<id>ecbe1a07c507d37aeb5f0f9ce1c4cc20c70fec64</id>
<content type='text'>
Whenever we want to tell our payload about a path, we limit ourselves
to a reasonable amount of characters. So far we only passed in device
names - exceeding 16 chars was unlikely there.

However by now we also pass real file path information, so let's increase
the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi"
fit just fine.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Whenever we want to tell our payload about a path, we limit ourselves
to a reasonable amount of characters. So far we only passed in device
names - exceeding 16 chars was unlikely there.

However by now we also pass real file path information, so let's increase
the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi"
fit just fine.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Pass file path to payload</title>
<updated>2016-04-18T21:11:36+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-11T14:16:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c07ad7c03588ab7b8f87b6567ac9202cf32b9bbe'/>
<id>c07ad7c03588ab7b8f87b6567ac9202cf32b9bbe</id>
<content type='text'>
The payload gets information on where it got loaded from. This includes
the device as well as file path.

So far we've treated both as the same thing and always gave it the device
name. However, in some situations grub2 actually wants to find its loading
path to find its configuration file.

So let's split the two semantically separte bits into separate structs and
pass the loaded file name into our payload when we load it using "load".

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The payload gets information on where it got loaded from. This includes
the device as well as file path.

So far we've treated both as the same thing and always gave it the device
name. However, in some situations grub2 actually wants to find its loading
path to find its configuration file.

So let's split the two semantically separte bits into separate structs and
pass the loaded file name into our payload when we load it using "load".

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Add el torito support</title>
<updated>2016-04-18T21:11:36+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-04-11T14:16:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8c3df0bf2e530c6e6f592f5144ef4f456c9e0260'/>
<id>8c3df0bf2e530c6e6f592f5144ef4f456c9e0260</id>
<content type='text'>
When loading an el torito image, uEFI exposes said image as a raw
block device to the payload.

Let's do the same by creating new block devices with added offsets for
the respective el torito partitions.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When loading an el torito image, uEFI exposes said image as a raw
block device to the payload.

Let's do the same by creating new block devices with added offsets for
the respective el torito partitions.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Add GOP support</title>
<updated>2016-03-27T13:12:12+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-03-15T17:38:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=be8d324191f3cd2f4861629ccf69106d58aaa70f'/>
<id>be8d324191f3cd2f4861629ccf69106d58aaa70f</id>
<content type='text'>
The EFI standard defines a simple boot protocol that an EFI payload can use
to access video output.

This patch adds support to expose exactly that one (and the mode already in
use) as possible graphical configuration to an EFI payload.

With this, I can successfully run grub2 with graphical output.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The EFI standard defines a simple boot protocol that an EFI payload can use
to access video output.

This patch adds support to expose exactly that one (and the mode already in
use) as possible graphical configuration to an EFI payload.

With this, I can successfully run grub2 with graphical output.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Pass proper device path in on boot</title>
<updated>2016-03-16T01:30:14+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-03-04T00:10:14+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0f4060ebcb4f60287c456586cf089510e43ba339'/>
<id>0f4060ebcb4f60287c456586cf089510e43ba339</id>
<content type='text'>
EFI payloads can query for the device they were booted from. Because
we have a disconnect between loading binaries and running binaries,
we passed in a dummy device path so far.

Unfortunately that breaks grub2's logic to find its configuration
file from the same device it was booted from.

This patch adds logic to have the "load" command call into our efi
code to set the device path to the one we last loaded a binary from.

With this grub2 properly detects where we got booted from and can
find its configuration file, even when searching by-partition.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EFI payloads can query for the device they were booted from. Because
we have a disconnect between loading binaries and running binaries,
we passed in a dummy device path so far.

Unfortunately that breaks grub2's logic to find its configuration
file from the same device it was booted from.

This patch adds logic to have the "load" command call into our efi
code to set the device path to the one we last loaded a binary from.

With this grub2 properly detects where we got booted from and can
find its configuration file, even when searching by-partition.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Call fdt preparation functions</title>
<updated>2016-03-16T01:30:14+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-03-04T00:10:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dea2174d9d941db2ec64997779771a4b4c3527c2'/>
<id>dea2174d9d941db2ec64997779771a4b4c3527c2</id>
<content type='text'>
We have a nice framework around image fils to prepare a device tree
for OS execution. That one patches in missing device tree nodes and
fixes up the memory range bits.

We need to call that one from the EFI boot path too to get all those
nice fixups. This patch adds the call.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have a nice framework around image fils to prepare a device tree
for OS execution. That one patches in missing device tree nodes and
fixes up the memory range bits.

We need to call that one from the EFI boot path too to get all those
nice fixups. This patch adds the call.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Add "bootefi" command</title>
<updated>2016-03-16T01:29:47+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2016-03-09T23:27:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b9939336d09ddc01e9e9d4e6a654f54f28decb12'/>
<id>b9939336d09ddc01e9e9d4e6a654f54f28decb12</id>
<content type='text'>
In order to execute an EFI application, we need to bridge the gap between
U-Boot's notion of executing images and EFI's notion of doing the same.

The best path forward IMHO here is to stick completely to the way U-Boot
deals with payloads. You manually load them using whatever method to RAM
and then have a simple boot command to execute them. So in our case, you
would do

  # load mmc 0:1 $loadaddr grub.efi
  # bootefi $loadaddr

which then gets you into a grub shell. Fdt information known to U-boot
via the fdt addr command is also passed to the EFI payload.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Simon Glass &lt;sjg@chromium.org&gt;
[trini: Guard help text with CONFIG_SYS_LONGHELP]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to execute an EFI application, we need to bridge the gap between
U-Boot's notion of executing images and EFI's notion of doing the same.

The best path forward IMHO here is to stick completely to the way U-Boot
deals with payloads. You manually load them using whatever method to RAM
and then have a simple boot command to execute them. So in our case, you
would do

  # load mmc 0:1 $loadaddr grub.efi
  # bootefi $loadaddr

which then gets you into a grub shell. Fdt information known to U-boot
via the fdt addr command is also passed to the EFI payload.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Simon Glass &lt;sjg@chromium.org&gt;
[trini: Guard help text with CONFIG_SYS_LONGHELP]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
