[U-Boot] uefi: x86: uboot as uefi payload

Simon Glass sjg at chromium.org
Wed Dec 7 04:47:33 CET 2016


Hi Markus,

On 5 December 2016 at 11:20, Markus Valentin <mv at denx.de> wrote:
> Hi Simon,
> On Sun, 2016-12-04 at 23:24 -0700, Simon Glass wrote:
>> Hi Markus,
>>
>> On 1 December 2016 at 01:58, Markus Valentin <mv at denx.de> wrote:
>> >
>> > Hi Simon,
>> > Am Mittwoch, den 30.11.2016, 19:20 -0700 schrieb Simon Glass:
>> > >
>> > > Hi Markus,
>> > >
>> > > On 30 November 2016 at 04:32, Markus Valentin <mv at denx.de> wrote:
>> > > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > im trying to run u-boot as uefi-payload for qemu this works totally
>> > > > fine.
>> > > >
>> > > > My real target is a Minnowboard Turbot. I did use the
>> > > > minnowmax_defconfig enabled CONFIG_EFI, CONFIG_EFI_STUB and
>> > > > CONFIG_EFI_STUB_64BIT. The Board has the latest uefi by Intel
>> > > > installed(0.93, X64).
>> > > >
>> > > > When i load U-Boot as payload for the board-uefi the efi_main
>> > > > function
>> > > > gets executed but the call to "cpu_call32" seems to get stuck ( i
>> > > > think
>> > > > its at the "retf" arch/x86/cpu/call32.S:37).
>> > > >
>> > > > Debuglog:
>> > > >
>> > > > Shell> u-boot-payload_64.efi
>> > > > U-Boot EFI Payload
>> > > > gdt: 00000047, addr: 00000000784fd570
>> > > > 00: 00000000  00000000
>> > > > 08: 00cf9200  0000ffff
>> > > > 10: 00af9a00  0000ffff
>> > > > 18: 00cf9300  0000ffff
>> > > > 20: 00cf9a00  0000ffff
>> > > > 28: 00000000  00000000
>> > > > 30: 00cf9200  0000ffff
>> > > > 38: 00af9b00  0000ffff
>> > > > 40: 00000000  00000000
>> > > >  32-bit code segment: 20
>> > > >  page_table: 79313000
>> > > >  EFI table at 78787018 size 00000760
>> > > >
>> > > > Does anyone have experiences with this issue or with running u-boot
>> > > > as
>> > > > uefi-64 payload at all?
>> > >
>> > > I have used this on the original Minnowboard and it is used on some
>> > > broadwell platforms.
>> > Great so i should be able to get it working too.
>> > >
>> > >
>> > > I did hit a similar problem due to the 'ret' not generating the right
>> > > instruction. I thought it was fixed but I suppose it is not
>> > > impossible
>> > > that the gcc toolchains might generate different op codes in
>> > > different
>> > > situations.
>> > >
>> > > Which toolchain are you using?
>> > Im using the gcc6 from Debian/testing,(6.2.0-13) and glibc6 2.24-5.
>> >
>> > Can you suggest a Toolchain? Mine is probably too "current"?
>>
>> I was using 4.9.0 now but I'm not sure if that is what I tested with.
>> I'll try it again when I get a chance, but it will be a week or so as
>> I am travelling.
>
> I was not a matter of the the toolchain my SYS_TEXT_BASE was wrong
> (0xfff00000) for unknown reason.
>
> Once i created my own defconfig-file which sets the required KConfig-
> variables, the default from board/intel/minnowmax/Kconfig gets
> properly applied  I did use menuconfig before which did somehow not
> put the changes to the .config file.

That's the base used for U-Boot running from ROM. I thought it would
be relocatable to the text base would not matter, but indeed, that
value seems more like a ROM value than a RAM value.

Anyway I'm please you have it running.

Regards,
Simon


More information about the U-Boot mailing list