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

[Alexander Graf]

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?


Alex