[U-Boot] [U-Boot, v3, 1/5] efi_loader: Initial HII database protocols
agraf at suse.de
Mon Feb 11 14:28:58 UTC 2019
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 at 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 at linaro.org>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>> Thanks, applied to efi-next
> 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?
More information about the U-Boot