[U-Boot] [PATCH] efi: Update README.efi to clarify build and test instructions

[Stoppa, Igor]

Hi Bin,

On 14 August 2015 at 13:47, Bin Meng <bmeng.cn at gmail.com> wrote:
> The doc has a misleading 'make menuconfig' when building the EFI
> application and payload. Clarify this and also update information
> on test with QEMU.
>
> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
> ---
>
>  doc/README.efi | 28 ++++++++++++++++++----------
>  1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/doc/README.efi b/doc/README.efi
> index 7c95579..e4872ed 100644
> --- a/doc/README.efi
> +++ b/doc/README.efi
> @@ -49,18 +49,21 @@ Build Instructions
>  First choose a board that has EFI support and obtain an EFI implementation
>  for that board. It will be either 32-bit or 64-bit.

Here I would add something like:

Alternatively, you can opt for using QEMU and the OVMF, as detailed below.

>
> -To build U-Boot as an EFI application (32-bit EFI required), enable
> -CONFIG_EFI and CONFIG_EFI_APP. The efi-x86 config is set up for this.
> +To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
> +and CONFIG_EFI_APP. The efi-x86 config (efi-x86_defconfig) is set up for this.
>
> -To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust
> -an existing config to enable CONFIG_EFI, CONFIG_EFI_STUB and either
> -CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT.
> +To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust an
> +existing config (like qemu-x86_defconfig) to enable CONFIG_EFI, CONFIG_EFI_STUB
> +and either CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT.


It might also be useful to give a short explanation (or a link to a
short explanation, if you know of any) of EFI application vs EFI
payload.

I'm still not sure I got that right, even after consulting the EFI specs.

>  Then build U-Boot as normal, e.g.
>
> +For building an EFI application, run:
> +   make efi-x86_defconfig
> +   make

Why is this one named efi-x86_defconfig, while the other is not?
Could it be efi-x86-application_defconfig, or something similarly
stating what sort of EFI binary it is?

> +For building an EFI payload, run:
>     make qemu-x86_defconfig
> -   make menuconfig    (or make xconfig if you prefer)
> -   # change the settings as above
>     make

It is mostly redundant, but I'd still prefer to have a reference
defconfig that just works also for the payload. Maybe not one for each
word size, but at least one.

>
>  You will end up with one of these files:
> @@ -71,8 +74,9 @@ You will end up with one of these files:
>
>  Trying it out
>  -------------
> -Qemu is an emulator and it can emulate an x86 machine. You can run the
> -payload with something like this:
> +QEMU [1] is an emulator and it can emulate an x86 machine. Please make sure
> +your QEMU version is 2.3.0 or above to test this. You can run the payload with
> +something like this:
>
>     mkdir /tmp/efi
>     cp /path/to/u-boot*.efi /tmp/efi
> @@ -80,7 +84,8 @@ payload with something like this:
>
>  Add -nographic if you want to use the terminal for output. Once it starts
>  type 'fs0:u-boot-payload.efi'

This didn't work for me, with the Tianocore binary
I had to use uppercase for the drive name, as in:

FS0:u-boot-payload.efi

 to run the payload or 'fs0:u-boot-app.efi' to
> -run the application. 'bios.bin' is the EFI 'BIOS'.
> +run the application. 'bios.bin' is the EFI 'BIOS'. Check [2] to obtain a
> +prebuilt EFI BIOS for QEMU or you can build one from source as well.
>
>  To try it on real hardware, put u-boot-app.efi on a suitable boot medium,
>  such as a USB stick. Then you can type something like this to start it:
> @@ -235,3 +240,6 @@ common/cmd_efi.c
>  Ben Stoltz, Simon Glass
>  Google, Inc
>  July 2015
> +
> +[1] http://www.qemu.org
> +[2] http://www.tianocore.org/ovmf/
> --
> 1.8.2.1
>

One more thing that I found somewhat confusing, but maybe it's just
because of my very limited experience with U-Boot on x86: where is the
prompt supposed to appear vs where is the logging happening?

In some cases the logging seems to go to the screen (that's what I
used), but in some other cases the logging goes to a serial port.
And maybe (but I could have misunderstood) it goes also to some
reserved memory area (maybe inspected with an ICE/ICD tool?).

-- 
igor