[U-Boot] uefi: x86: uboot as uefi payload
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?
regard Markus
Hi Markus,
On 30 November 2016 at 04:32, Markus Valentin mv@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.
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?
Regards, Simon
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@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"?
Regards Markus
Hi Markus,
On 1 December 2016 at 01:58, Markus Valentin mv@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@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.
Regards, Simon
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@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@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.
Regards Markus
Hi Markus,
On 5 December 2016 at 11:20, Markus Valentin mv@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@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@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
participants (2)
-
Markus Valentin -
Simon Glass