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.lindh...@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.lindh...@linaro.org> > >>>Signed-off-by: Rob Clark <robdcl...@gmail.com> > >>>Signed-off-by: AKASHI Takahiro <takahiro.aka...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot