After successfully updating and re-configuring the Odroid C2 to use Fedora uefi/grub2 to boot, I decided to try to do the same to the even-older Hikey SOC.

This already booted using fastboot with an older version of grub, with manual configuration, but I wanted to use the standard (Fedora) boot process.

I had read that there was a ‘known-problem’ with fastboot on the Hikey, and it could only access the eMMC during the initial stages of the pre-kernel-load boot process, and tests proved this to be the case. Booting into grub worked OK, but referencing the SDCard produced a
../../grub-core/kern/disk_common.c:46:attempt to read or write outside of disk `hd1'
error message, and from the grub boot prompt the top-level directories on the SDCard (hd1,1) listed OK, but their contents could not be accessed.
Fortunately the 3GB eMMC has sufficient accessible space for the /EFI and /boot directories, and so I moved the entire boot directory contents from the SDcard to the larger partition (EXT4) on the eMMC. and the (Fedora) EFI contents to the smaller (FAT16) eMMC partition..

The system is basically a ‘naked’ phone with the ability to boot Linux, so the built-in eMMC has a typical Android phone partition layout:
Model: MMC MMC04G (sd/mmc)
Disk /dev/mmcblk0: 3926MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB vrl msftdata
2 2097kB 3146kB 1049kB vrl_backup msftdata
3 3146kB 4194kB 1049kB mcuimage msftdata
4 4194kB 12.6MB 8389kB fastboot bios_grub
5 12.6MB 14.7MB 2097kB nvme msftdata
6 14.7MB 81.8MB 67.1MB fat16 boot boot, esp
7 81.8MB 350MB 268MB reserved msftdata
8 350MB 619MB 268MB cache
9 619MB 3825MB 3207MB ext4 system msftdata
– which appear in Linux as:
brw-rw---- 1 root disk 179, 32 Sep 3 06:40 /dev/mmcblk0boot0
brw-rw---- 1 root disk 179, 64 Sep 3 06:40 /dev/mmcblk0boot1
brw-rw---- 1 root disk 179, 1 Sep 9 17:29 /dev/mmcblk0p1
brw-rw---- 1 root disk 179, 2 Sep 9 17:29 /dev/mmcblk0p2
brw-rw---- 1 root disk 179, 3 Sep 9 17:29 /dev/mmcblk0p3
brw-rw---- 1 root disk 179, 4 Sep 9 17:29 /dev/mmcblk0p4
brw-rw---- 1 root disk 179, 5 Sep 9 17:29 /dev/mmcblk0p5
brw-rw---- 1 root disk 179, 6 Sep 9 17:29 /dev/mmcblk0p6
brw-rw---- 1 root disk 179, 7 Sep 9 17:29 /dev/mmcblk0p7
brw-rw---- 1 root disk 179, 8 Sep 9 17:29 /dev/mmcblk0p8
brw-rw---- 1 root disk 179, 9 Sep 9 17:29 /dev/mmcblk0p9
crw------- 1 root root 244, 0 Sep 3 06:40 /dev/mmcblk0rpmb

With these changes, the system booted into grub, and displayed the usual Fedora menu.
I then tested compiling a standard kernel on the system, but found that the result hung on booting. For some reason, the initramfs image was not being created as part of the kernel install, and so I had to create it manually each time, from the /boot directory:
# dracut -v initramfs-<kernel version>.img <kernel version>
This has to be done before running grub-customizer, or the corresponding initrd…….. parameter will not be added to the grub boot instructions, and the boot will hang.
Remember – if you want it – to install busybox in advance, so this will be included with the initramfs.. creation.
The fstab entry looks like this:
# cat /etc/fstab
UUID=<SDCard, Partition 1 UUID> /         ext4 defaults 1 1
UUID=<eMMC, Partition 6 UUID>   /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=<eMMC, Partition 9 UUID>   /boot     ext4 defaults 1 2
/SWAP                           none      swap defaults 0 0

A major issue with this system, is that it overheats chronically – and always has.
I run kernel compiles single-threaded, but still get occasional compiler ‘crashes’, with
[ 174.353880] hisi_thermal f7030700.tsensor: sensor <2> THERMAL ALARM stopped: 61675 < 65000
[ 5617.609038] hisi_thermal f7030700.tsensor: sensor <2> THERMAL ALARM: 66385 > 65000
[ 5649.617335] hisi_thermal f7030700.tsensor: sensor <2> THERMAL ALARM stopped: 61675 < 65000
[ 5652.562227] hisi_thermal f7030700.tsensor: sensor <2> THERMAL ALARM: 66385 > 65000
[ 5696.207883] hisi_thermal f7030700.tsensor: sensor <2> THERMAL ALARM stopped: 61675 < 65000

So – time to invest in a larger heatsink, and fan!

Robert Gadsdon. September 9th, 2019.