[U-Boot] x86: EFI: boot fails at exit_boot_services - Was: Stuck trying to build a non-qemu EFI payload

[Simon Glass]

Hi Igor,

On 25 August 2015 at 07:18, Stoppa, Igor <igor.stoppa at intel.com> wrote:
> Hi Simon,
> thanks for helping, please find my reply below.
>
> On 21 August 2015 at 23:51, Simon Glass <sjg at chromium.org> wrote:
>
>> Note that once you call exit_boot_services you will not be able to use
>> the console. Be careful here - the board may appear to hang but
>> actually it is broken by you trying to output to the console.
>
> Yes, I had realised it, but it seemed - on qemu - that it would still
> work to call "putc", after the code:
>
>> map.version = version;
>> map.desc_size = desc_size;
>> add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map), desc, size);
>> add_entry_addr(priv, EFIET_END, NULL, 0, 0, 0);
>
> But maybe I was just "lucky" and it worked even if it was not supposed to.
> For example, maybe it was using memory pages that had already been freed.
>
> However, after your reply, I re-cloned the x86 branch, just to be sure
> I would be starting from a clean slate, and re-did the configuration
> from scratch, without adding any traces.
>
> The result is that stub reaches the call "jump_to_uboot", so it seems
> that there are no problems there.
>
> The issues are to be found in the payload (as expected, since I'm
> using the qemu defconfig).
>
> Trying the QEMU image on my Haswell test device, I see it rebooting.
>
> Since I do not have means to obtain a serial console (please see
> footer note), I resorted to using a "while(1);" to identify the point
> where the reboot happens, by turning the reboot into a hang.
>
> The location where the reboot is triggered is in:
>
>  common/board_f.c: board_init_f_mem @
> 1048:  memset(gd_ptr, '\0', sizeof(*gd));
>
> I do not know the value of the pointer, but it seems that it is
> incorrect and writing to this address causes a reset.

You might be able to output it with printhex8() if not too early.

This is supposed to be in cache-as-RAM space. See start.S where it
calls that function. The FSP returns that value so I'm not sure what
could be wrong.

>
> I wonder if this is because I'm still using the device tree for the
> machine emulated by QEMU and if I should build one for my specific
> Haswell NUC.
>
> Btw, the EFI bios offers the option of printing the EFI device tree.
> Is it the same used by U-Boot, so that I could use this information to
> create the Device Tree file?

I don't think the device tree matters. Also we use the open firmware
device tree (as Linux) - I thought EFI had its own thing?

>
> --
> thanks, igor

Regards,
Simon