On Tue, Feb 9, 2016 at 1:11 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Mon, Feb 08, 2016 at 02:49:59PM -0200, Ricardo Salveti wrote:
On Mon, Feb 8, 2016 at 2:37 PM, Steve McIntyre
Oh, ugh. What's the problem with the EFI variables? From a Debian perspective, you could (almost) get away with using the workaround I developed for broken firmware that doesn't do EFI properly. See http://bugs.debian.org/746662 for the full story if you're interested. There's support in Debian to track this automatically, and it's preseedable too if you need that.
Isn't the variables here the runtime support (for efibootmng)? If so, that is not supported by hikey.
:-(
However (as Mark says), if it's looking for (ESP)/EFI/BOOT/grubaa64.efi then it's wrong. The removable media path should be (ESP)/EFI/BOOT/bootaa64.efi, or have you mis-typed that in your mail here? (I hope so!)
This is probably why (which is known to be broken):
HisiPkg/HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c [HIKEY_BOOT_ENTRY_BOOT_EMMC] = { L"VenHw(B549F005-4BD4-4020-A0CB-06F42BDA68C3)/HD(6,GPT,5C0F213C-17E1-4149-88C8-8B50FB4EC70E,0x7000,0x20000)/\EFI\BOOT\GRUBAA64.EFI", NULL, L"boot from eMMC", LOAD_OPTION_CATEGORY_APP },
Oh, ick. I see. That's... special.
Yup. We're blazing new trails here. Aside from enterprise class systems*, all ARM UEFI ports are dealing with this pain. However, once we've got it sorted for HiKey then that solution should pretty much carry over to all platforms with eMMC and UEFI.
g.
* Enterprise class systems generally have completely separate storage for firmware that look remarkably like equivalent x86 hardware.