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