On 2016-02-22 14:26, Michael Howard wrote: > On 22/02/2016 11:50, Gordan Bobic wrote: >> It seems a little odd that the installer would put the kernel >> somewhere >> other than the target installation disk. Having UEFI on-board I can >> understand, but shouldn't the boot sequence in this case be: >> >> 1) u-boot (on-board) >> 2) UEFI (wherever u-boot can fetch it from) >> 3) grub (off the UEFI FAT partition on the target disk) >> 4) Kernel (/boot partition) >> >> Is there a good reason for deviating from this? >> > > Ok, reinstalling the original u-boot resolves the onboard kernel > issue, that is, the board now boots to OpenLinux again when no other > devices are attached. So the 'Applied Micro Linux 3.12.0 (aarch64)' > kernel is part of their (Gigabyte's) u-boot image. Right, so now that UEFI is working, it seems the next thing to do is to get grub2 loading from UEFI. From there on it should be trivial to get a sensible kernel booting. I do find it baffling that the installer that requires UEFI would do something so fundamentally different in terms of configuring the boot process compared to the x86 method of doing it. Hmm... I wonder... Did you create a 250MB FAT partition on the disk of type EF00 (GPT), for the UEFI boot loader part (the stuff that ends up in /boot/efi)? Gordan