On Mon, Feb 8, 2016 at 5:46 PM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Mon, Feb 8, 2016 at 3:17 PM, Mark Rutland mark.rutland@arm.com 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 steve.mcintyre@linaro.org wrote:
On Mon, Feb 08, 2016 at 03:35:36PM +0000, Grant Likely wrote:
Hi all,
I've spent some time over the past couple of days getting update-grub working on the hikey. It works for me, but I need some review. The solution consists of three parts:
- a new config file in /etc/default/kernel that can contain
KERNEL_DEVICETREE="<board-name>" 2) a new script in /etc/kernel/postinst.d/devicetree that copies the requested device tree file into /boot when KERNEL_DEVICETREE is set 3) a modifcation to /etc/grub.d/10_linux that will add the devicetree command when KERNEL_DEVICETREE is set.
Hmmmm. Other machines aren't needing to know the specific devicetree in this way.
That is probably because the firmware is providing a valid device tree by default.
I've also be partially successful using the grub-install tool. It will install the grubaa64.efi application correctly in (ESP)/EFI/debian/grubaa64.efi, but barfs when trying to update the EFI variables which is unsurprising. However, the system boots fine when I copy the installed grubaa64.efi into (ESP)/EFI/BOOT/grubaa64.efi
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)?
Yes. The boot variables are like any other variables, and are manipulated via runtime services (e.g. SetVariable).
If so, that is not supported by hikey.
Is there any route to having them supported? I don't know enough about HiKey to know whether it's not possible, very difficult, or simply not worked on.
They are required per the EFI spec, and it's an unfortunate divergence given they're key to the usual boot flow.
Haojian, since you are restructuring the code as we speak, would it be even possible to support runtime here?
Since you are already storing meta-data in a specific disk partition, wouldn't it be possible to reuse the same logic to make runtime supported?
The hard part of SetVariable on eMMC is that he firmware cannot touch the eMMC device while the kernel is running. One of two things must be done: 1) Store all changes in memory and wait until ResetSystem() is called to write out to eMMC. Downside: Changes are lost if the system crashes/reboots without calling ResetSystem() 2) Have a kernel driver that stores variable updates on UEFI's behalf. UEFI will need to call back out to the kernel to request write cycles Downside: violates UEFI spec not requiring any kernel involvement to store variables --- However, given the nature of the hardware, I don't think this violates the intent of the spec and I believe there is work in progress to get the spec adjusted for the eMMC use case.
g.