[U-Boot] [U-Boot, v3, 1/5] efi_loader: Initial HII database protocols

[AKASHI Takahiro]

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 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
> >>
> >>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
>