Re: [U-Boot] [U-Boot, v3, 1/5] efi_loader: Initial HII database protocols
On 1/23/19 2:01 PM, Alexander Graf wrote:
From: Leif Lindholm leif.lindholm@linaro.org
This patch provides enough implementation of the following protocols to run EDKII's Shell.efi and UEFI SCT:
- EfiHiiDatabaseProtocol
- EfiHiiStringProtocol
Not implemented are:
- ExportPackageLists()
- RegisterPackageNotify()/UnregisterPackageNotify()
- SetKeyboardLayout() (i.e. *current* keyboard layout)
HII database protocol in this patch series can handle only:
- GUID package
- string package
- keyboard layout package
(The other packages, except Device path package, will be necessary for interactive and graphical UI.)
Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Rob Clark robdclark@gmail.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
Thanks, applied to efi-next
Alex
I have rebased the efi-next tree upon U-Boot master. My Odroid C2 crashes when booting via U-Boot -> iPXE -> GRUB -> Linux. Bisection points to this patch. The HII protocols are referenced by iPXE if available.
An interesting comment in https://www.spinics.net/lists/arm-kernel/msg704238.html for a similar U-Boot related error is:
"Looks like you're taking the SError as soon as we unmask them, so it could've been pending for ages. It would be interesting to see if it's actually caused by the kernel, or if the firmware triggers it beforehand."
Booting via iPXE is described in doc/README.iscsi
This patch and some follow up patches are included in the pull request for the EFI tree.
I would prefer if we could remove the HII protocols from the pull request until the patches are thoroughly tested.
Loading Linux 4.19.0-1-arm64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 4.19.0-1-arm64 (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8) [ 0.000000] Machine model: Hardkernel ODROID-C2 [ 0.000000] earlycon: meson0 at MMIO 0x00000000c81004c0 (options '115200n8') [ 0.000000] bootconsole [meson0] enabled [ 0.000000] SError Interrupt on CPU0, code 0xbf000000 -- SError [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-1-arm64 #1 Debian 4.19.12-1 [ 0.000000] Hardware name: Hardkernel ODROID-C2 (DT) [ 0.000000] pstate: 00000085 (nzcv daIf -PAN -UAO) [ 0.000000] pc : setup_arch+0x104/0x570 [ 0.000000] lr : setup_arch+0xfc/0x570 [ 0.000000] sp : ffff000009293f10 [ 0.000000] x29: ffff000009293f10 x28: 00000000023d0018 [ 0.000000] x27: 000000007c9b30c0 x26: 0000000000000000 [ 0.000000] x25: 0000000000000000 x24: 000000007ca7e000 [ 0.000000] x23: 0000000000000000 x22: ffff000009299708 [ 0.000000] x21: ffff7dfffe8000d4 x20: ffff0000092e3330 [ 0.000000] x19: ffff000008080000 x18: 0000000000000010 [ 0.000000] x17: 0000000000000000 x16: 0000000000000000 [ 0.000000] x15: ffffffffffffffff x14: ffff000009299708 [ 0.000000] x13: ffff00008943937f x12: 0000000000000028 [ 0.000000] x11: 0000000000000007 x10: 0101010101010101 [ 0.000000] x9 : fffffffffffffffb x8 : 0000000000000008 [ 0.000000] x7 : 0000000000000003 x6 : 0000000000800000 [ 0.000000] x5 : 0000800000000000 x4 : 0000000000000065 [ 0.000000] x3 : 0000000000000063 x2 : 0000000000000000 [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000080 [ 0.000000] Kernel panic - not syncing: Asynchronous SError Interrupt [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-1-arm64 #1 Debian 4.19.12-1 [ 0.000000] Hardware name: Hardkernel ODROID-C2 (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x0/0x180 [ 0.000000] show_stack+0x24/0x30 [ 0.000000] dump_stack+0x90/0xb4 [ 0.000000] panic+0x128/0x290 [ 0.000000] nmi_panic+0x7c/0x80 [ 0.000000] arm64_serror_panic+0x80/0x8c [ 0.000000] is_valid_bugaddr+0x0/0x1c [ 0.000000] el1_error+0x7c/0xdc [ 0.000000] setup_arch+0x104/0x570 [ 0.000000] start_kernel+0x78/0x4c0
Best regards
Heinrich
On 02/09/2019 05:19 PM, Heinrich Schuchardt wrote:
On 1/23/19 2:01 PM, Alexander Graf wrote:
From: Leif Lindholm leif.lindholm@linaro.org
This patch provides enough implementation of the following protocols to run EDKII's Shell.efi and UEFI SCT:
- EfiHiiDatabaseProtocol
- EfiHiiStringProtocol
Not implemented are:
- ExportPackageLists()
- RegisterPackageNotify()/UnregisterPackageNotify()
- SetKeyboardLayout() (i.e. *current* keyboard layout)
HII database protocol in this patch series can handle only:
- GUID package
- string package
- keyboard layout package
(The other packages, except Device path package, will be necessary for interactive and graphical UI.)
Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Rob Clark robdclark@gmail.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
Thanks, applied to efi-next
Alex
I have rebased the efi-next tree upon U-Boot master. My Odroid C2 crashes when booting via U-Boot -> iPXE -> GRUB -> Linux. Bisection points to this patch. The HII protocols are referenced by iPXE if available.
An interesting comment in https://www.spinics.net/lists/arm-kernel/msg704238.html for a similar U-Boot related error is:
"Looks like you're taking the SError as soon as we unmask them, so it could've been pending for ages. It would be interesting to see if it's actually caused by the kernel, or if the firmware triggers it beforehand."
Booting via iPXE is described in doc/README.iscsi
This patch and some follow up patches are included in the pull request for the EFI tree.
I would prefer if we could remove the HII protocols from the pull request until the patches are thoroughly tested.
I've posted a patch to remove only the protocol exposure. That way we can leave most bits in.
The #SError sounds like something is trying to write to a memory location that is not backed by a device. That is usually an indicator for a NULL dereference. Maybe by looking at the respective iPXE code, you will be able to find the spot that does the invalid access?
Alex
Alex, Heinrich,
On Mon, Feb 11, 2019 at 03:28:58PM +0100, Alexander Graf wrote:
On 02/09/2019 05:19 PM, Heinrich Schuchardt wrote:
On 1/23/19 2:01 PM, Alexander Graf wrote:
From: Leif Lindholm leif.lindholm@linaro.org
This patch provides enough implementation of the following protocols to run EDKII's Shell.efi and UEFI SCT:
- EfiHiiDatabaseProtocol
- EfiHiiStringProtocol
Not implemented are:
- ExportPackageLists()
- RegisterPackageNotify()/UnregisterPackageNotify()
- SetKeyboardLayout() (i.e. *current* keyboard layout)
HII database protocol in this patch series can handle only:
- GUID package
- string package
- keyboard layout package
(The other packages, except Device path package, will be necessary for interactive and graphical UI.)
Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Rob Clark robdclark@gmail.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
Thanks, applied to efi-next
Alex
I have rebased the efi-next tree upon U-Boot master. My Odroid C2 crashes when booting via U-Boot -> iPXE -> GRUB -> Linux. Bisection points to this patch. The HII protocols are referenced by iPXE if available.
An interesting comment in https://www.spinics.net/lists/arm-kernel/msg704238.html for a similar U-Boot related error is:
"Looks like you're taking the SError as soon as we unmask them, so it could've been pending for ages. It would be interesting to see if it's actually caused by the kernel, or if the firmware triggers it beforehand."
Booting via iPXE is described in doc/README.iscsi
This patch and some follow up patches are included in the pull request for the EFI tree.
I would prefer if we could remove the HII protocols from the pull request until the patches are thoroughly tested.
I've posted a patch to remove only the protocol exposure. That way we can leave most bits in.
The #SError sounds like something is trying to write to a memory location that is not backed by a device. That is usually an indicator for a NULL dereference. Maybe by looking at the respective iPXE code, you will be able to find the spot that does the invalid access?
Taking a quick look at iPXE code (src/interface/efi/*), it uses * HII_PACKAGE_FORMS * HII_PACKAGE_STRINGS * HII_CONFIG_ROUTING_PROTOCOL * HII_CONFIG_ACCESS_PROTOCOL but my current patch doesn't support neither PACKAGE_FORMS nor CONFIG_*_PROTOCOL. One of those might be a root cause. (I don't know when and how SError was triggered though.)
-Takahiro Akashi
Alex
participants (3)
-
AKASHI Takahiro -
Alexander Graf -
Heinrich Schuchardt