bzImage under x86_64 UEFI app mode.
Hi. I'm trying the new UEFI-app mode where I rely on EFI services to give me access to things like block devices etc. I'm currently using 2022.04-rc1. So far so good. I can start U-boot and the efi block device works just fine. But I'm not succeeding in booting a regular bzImage. This kernel (5.16.4) configuration works on both the physical hardware and an UEFI x86_64 VBox instance using Barebox 2021.08, so kernel configuration should in theory be ok. It's a bzImage with a efistub. I can load a kernel or kernel+initrd baked in, verify the data and use zboot on the loadaddr. zboot does not complain afaics. The kernel however, does not seem to make it very far. Valid Boot Flag Setup Size = 0x3a00 Magic signature found Using boot protocol version 2.0f Linux kernel version 5.16.4 (ptxdist@ptxdist) #4 SMP PREEMPT 2022-02-01T00:00:00+00:00 Building boot_params at 0x0009 Loading bzImage at address 10 (69330784 bytes) Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Setup E820 entries Setup cmdline Kernel command line:console=$(console) rdinit=/sbin/init quiet rw secpboot=factoryimage Kernel command line: "console=tty0 rdinit=/sbin/init quiet rw secpboot=factoryimage" Setup devicetree Kernel loaded at 0010, setup_base=0009 Starting kernel ... tsc-timer: When removing: flags=600, drv->flags=0, err=-129 serial: When removing: flags=600, drv->flags=0, err=-129 efi-fb.vidconsole0: When removing: flags=600, drv->flags=0, err=-129 efi-fb: When removing: flags=600, drv->flags=0, err=-129 efi_media.blk: When removing: flags=600, drv->flags=0, err=-129 efi_media_0: When removing: flags=600, drv->flags=0, err=-129 root_driver: When removing: flags=600, drv->flags=0, err=-129 X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 0010001A, CS - 0038, RFLAGS - 00010006 RAX - 0431E490, RCX - , RDX - FFFB RBX - , RSP - 000901E8, RBP - 0010 RSI - 0009, RDI - R8 - 0020, R9 - 000A, R10 - 000D R11 - 0008, R12 - 0009, R13 - DB2372C8 R14 - D9D0D9D8, R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - C0010033, CR2 - , CR3 - DB001000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - DAFF2018 0047, LDTR - IDTR - DAC04018 0FFF, TR - FXSAVE_STATE - 0008FE40 Can't find image information. Hints?
Re: [PATCH v5 27/28] x86: efi: Set the correct link flags for the 64-bit EFI app
On 12/4/21 16:56, Simon Glass wrote: > At present some 32-bit settings are used with the 64-bit app. Fix this by > separating out the two cases. > > Be careful not to break the 64-bit payload, which needs to build a 64-bit > EFI stub with a 32-bit U-Boot. > > Signed-off-by: Simon Glass Signed-off-by: Christian Melki > --- > > Changes in v5: > - Add new patch to set the correct link flags for the 64-bit EFI app > > arch/x86/config.mk | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > index 589f2aed2bc..889497b6bd7 100644 > --- a/arch/x86/config.mk > +++ b/arch/x86/config.mk > @@ -20,6 +20,11 @@ IS_32BIT := y > endif > endif > > +EFI_IS_32BIT := $(IS_32BIT) > +ifdef CONFIG_EFI_STUB_64BIT > +EFI_IS_32BIT := > +endif > + > ifeq ($(IS_32BIT),y) > PLATFORM_CPPFLAGS += -march=i386 -m32 > else > @@ -44,8 +49,14 @@ CFLAGS_EFI := -fpic -fshort-wchar > # Compiler flags to be removed when building UEFI applications > CFLAGS_NON_EFI := -mregparm=3 -fstack-protector-strong > > -ifeq ($(CONFIG_EFI_STUB_64BIT),) > +ifeq ($(IS_32BIT),y) > +EFIPAYLOAD_BFDARCH = i386 > +else > CFLAGS_EFI += $(call cc-option, -mno-red-zone) > +EFIPAYLOAD_BFDARCH = x86_64 > +endif > + > +ifeq ($(EFI_IS_32BIT),y) > EFIARCH = ia32 > EFIPAYLOAD_BFDTARGET = elf32-i386 > else > @@ -53,8 +64,6 @@ EFIARCH = x86_64 > EFIPAYLOAD_BFDTARGET = elf64-x86-64 > endif > > -EFIPAYLOAD_BFDARCH = i386 > - > LDSCRIPT_EFI := $(srctree)/arch/x86/lib/elf_$(EFIARCH)_efi.lds > EFISTUB := crt0_$(EFIARCH)_efi.o reloc_$(EFIARCH)_efi.o > OBJCOPYFLAGS_EFI += --target=efi-app-$(EFIARCH) >
Re: [PATCH v5 26/28] x86: efi: Don't use the 64-bit link script for the EFI app
On 12/4/21 16:56, Simon Glass wrote: > That script is not intended for use with EFI, so update the logic to avoid > using it. > > Signed-off-by: Simon Glass Signed-off-by: Christian Melki > --- > > Changes in v5: > - Add new patch to avoid using the 64-bit link script for the EFI app > > arch/x86/cpu/config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/cpu/config.mk b/arch/x86/cpu/config.mk > index d3033b41603..87e242a2065 100644 > --- a/arch/x86/cpu/config.mk > +++ b/arch/x86/cpu/config.mk > @@ -9,7 +9,7 @@ LDPPFLAGS += -DRESET_VEC_LOC=$(CONFIG_RESET_VEC_LOC) > LDPPFLAGS += -DSTART_16=$(CONFIG_SYS_X86_START16) > > ifdef CONFIG_X86_64 > -ifndef CONFIG_SPL_BUILD > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_EFI_APP),) > LDSCRIPT = $(srctree)/arch/x86/cpu/u-boot-64.lds > endif > endif >
Re: Hints on how to use efi_driver/efi_block_device.c
On 8/13/21 2:36 AM, Heinrich Schuchardt wrote: On 8/12/21 11:49 PM, Simon Glass wrote: +Heinrich Schuchardt too On Thu, 12 Aug 2021 at 08:35, Christian Melki wrote: I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard. Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this. Hello Christian, U-Boot can be used in two scenarios: 1) U-Boot is the firmware providing the UEFI API 2) U-Boot is running as an application consuming the UEFI API. Barebox only supports scenario 2). Ok. I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it. efi_driver/efi_block_device.c is used in scenario 1). When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a handle and calls ConnectController() U-Boot will install the EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device. You can find a detailed description of this use case in: * https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html * https://archive.fosdem.org/2020/schedule/event/firmware_duwu/ I read the fosdem presentation, but apparently did not understand it correctly, as I thought it could be used for presenting the UEFI block IO protocol. Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware. Here you seem be referring to scenario 2). For scenario 2) support for UEFI block devices has not been implemented, yet. As operating systems like Linux, BSD, Windows all can be booted via UEFI there has not been any use case driving further development of this scenario. Please, describe what you want to do with U-Boot. I have an x86 board (DFI GHF51, AMD Ryzen R1000) with an ACPI presented eMMC. AMDI0040. U-boot does not seem to recognize this device (Linux works fine. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-acpi.c). So I thought the UEFI block IO protocol could come in handy as a generic abstraction. The device works fine under Barebox with this mechanism. So without a native or an UEFI block IO driver I have no disc access in U-boot. I know that UEFI can boot a EFI-stubbed kernel directly. But I am more comfortable with the U-boot "ecosystem" than UEFI, also it is easier to merge more platforms under the same (existing) boot mechanism/behavior/environment using U-boot as an intermediate than just UEFI (older ARM/PPC etc). So definitely an use-case for me. Thanks in advance, Christian Best regards Heinrich
Hints on how to use efi_driver/efi_block_device.c
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard. Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this. I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it. Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware. Best regards, Christian
Re: [PATCH] x86: Ensure the e820 map is installed in all cases
Simon. Sorry for the late reply.
Tested on Virtualbox and on real hardware (DFI GHF51).
Works for me.
On 7/11/21 5:15 AM, Simon Glass wrote:
> This is a revert of a recent logic change in setup_zimage(). We do
> actually need to install this information always. Change it to install
> from the Coreboot tables if available, else the normal source.
>
> Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from
> coreboot")
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/lib/zimage.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 90fc8a466d7..cf4210cd4ba 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -313,12 +313,12 @@ int setup_zimage(struct boot_params *setup_base, char
> *cmd_line, int auto_boot,
> int bootproto = get_boot_protocol(hdr, false);
>
> log_debug("Setup E820 entries\n");
> - if (ll_boot_init()) {
> - setup_base->e820_entries = install_e820_map(
> - ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> - } else if (IS_ENABLED(CONFIG_COREBOOT_SYSINFO)) {
> + if (IS_ENABLED(CONFIG_COREBOOT_SYSINFO)) {
> setup_base->e820_entries = cb_install_e820_map(
> ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> + } else {
> + setup_base->e820_entries = install_e820_map(
> + ARRAY_SIZE(setup_base->e820_map), setup_base->e820_map);
> }
>
> if (bootproto == 0x0100) {
>
Re: U-Boot zboot on x86-64 VirtualBox UEFI.
On 6/11/21 3:40 PM, Simon Glass wrote: > +Heinrich Schuchardt > > Hi Christian, > > On Fri, 11 Jun 2021 at 07:30, Christian Melki > wrote: >> >> Hi. >> >> I have been trying to boot a bzImage with zboot from a VirtualBox UEFI >> instance -> U-Boot UEFI payload. So far I've been using 2021.07-rc1. I'd >> like to try a newer rc, but even if built exactly the same with the same >> .config, newer won't boot as an UEFI payload. So right now, I'm stuck at >> rc1. >> >> Anyway. >> The kernel in question starts when configured with an EFI stub from the >> UEFI shell. >> >> U-boot fails to boot the bzImage from the console using zboot though. >> Just freezes after "Starting kernel..." > > We don't actually have tests for this in CI at present. > > I don't see any changes in the zboot stuff though. There is quite a > bit in efi_loader. You could perhaps try a bisect. I can live with 2021.07-rc1 right now as it atleast starts as an UEFI payload. But my big issue is that I can't start the kernel with zboot. Full debug build isn't that much more informative either. I was thinking different load offsets, but mine seems pretty much standard, so I don't know. I've played around a bit with configuration on both halves, but it doesn't help. > > Heinrich, do you have any ideas? > >> >> zboot 0108 - 0400 319c000 >> Valid Boot Flag >> Magic signature found >> Linux kernel version 5.12.0 (ptxdist@ptxdist) #2 SMP PREEMPT >> 2021-06-01T00:00:00+00:00 >> Building boot_params at 0x0009 >> Loading bzImage at address 10 (6516096 bytes) >> Initial RAM disk at linear address 0x0400, size 52019200 bytes >> Kernel command line: "console=ttyS0,115200 rw quiet" >> Kernel loaded at 0010, setup_base=0009 >> >> Starting kernel ... >> >> Any ideas? > > Regards, > Simon >
Re: [PATCH] Add udivmoddi4.
On 6/9/21 8:31 PM, Tom Rini wrote:
> On Mon, Jun 07, 2021 at 11:20:47AM +0200, Christian Melki wrote:
>
>> A newer toolchain will emit udivmoddi4 for certain divide + modulo
>> operations instead of a separate divide and modulo operation.
>> AFAIU, this would be sufficient.
>>
>> Signed-off-by: Christian Melki
>> ---
>> arch/x86/lib/div64.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
>> index 2bea205f60..a5b536fbc5 100644
>> --- a/arch/x86/lib/div64.c
>> +++ b/arch/x86/lib/div64.c
>> @@ -110,3 +110,8 @@ u64 __umoddi3(u64 num, u64 den)
>> _64bit_divide(num, den, );
>> return v;
>> }
>> +
>> +u64 __udivmoddi4(u64 num, u64 den, u64 *rem)
>> +{
>> +return _64bit_divide(num, den, rem);
>> +}
>
> How do you trigger this and should you not be using do_div(), etc,
> instead?
>
I probably should. Was trying to minimize various dependencies on u-boot
code (atleast with function separation) while trying to implement a
redundancy boot mechanism as a cmd. Triggered by using two consecutive
calls between the same variables for division and remainder as pure
operands with a gcc 9.3 x86 toolchain.
U-boot has no div_up afaik?
a = b / c;
if (b % c) {
a++;
}
b / c and b % c gets optimized / translated to udivmoddi4 as one operation.
[PATCH] disk/part_dos.c: Fix what looks like a variable typo in the write functionality.
Signed-off-by: Christian Melki --- disk/part_dos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/disk/part_dos.c b/disk/part_dos.c index 60addc6e00..9e29aa6583 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -424,7 +424,7 @@ int write_mbr_partitions(struct blk_desc *dev, } /* Update the partition table entries*/ - part_init(dev_desc); + part_init(dev); return 0; } -- 2.31.1
[PATCH] Add udivmoddi4.
A newer toolchain will emit udivmoddi4 for certain divide + modulo
operations instead of a separate divide and modulo operation.
AFAIU, this would be sufficient.
Signed-off-by: Christian Melki
---
arch/x86/lib/div64.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
index 2bea205f60..a5b536fbc5 100644
--- a/arch/x86/lib/div64.c
+++ b/arch/x86/lib/div64.c
@@ -110,3 +110,8 @@ u64 __umoddi3(u64 num, u64 den)
_64bit_divide(num, den, );
return v;
}
+
+u64 __udivmoddi4(u64 num, u64 den, u64 *rem)
+{
+ return _64bit_divide(num, den, rem);
+}
--
2.31.1
