When the Odroid C2 was first released way back in 2016, I spent ages trying to get it to function correctly with a mainstream kernel, and tested innumerable development versions of U-Boot, including functionality that was working OK at that time, but that – for some reason – then failed to be included in the ‘mainstream’ U-Boot..
One of the enduring problems was the lack of functionality for kernel upgrades, as U-Boot on the C2 did not include the facility for permanently updating the environment – no ‘saveenv‘ capability, and having to use boot script/images was clumsy and time-consuming, to say the least..
As I had Fedora 30 with grub2 working on the Raspberry Pi 3, I recently returned to the possibility of doing the same for the Odroid C2. The Pi 3 version of Fedora 30 with grub used the ‘traditional’ Pi boot scripts, but I needed to get grub working with the C2 version of U-Boot etc..
I had already managed to get grub working, but it never got beyond the grub prompt, although it was then possible to load the grub config using
grub> configfile (hd0,1)/efi/fedora/grub.cfg
The usual search turned up a host of dead-end articles featuring not-quite-working setups, but I then decided to check the OpenSuse site, as I recalled that they were the first ones to get grub etc. working on the old Hikey ARM64 system that I had some years earlier.
I found a working version of OpenSuse for the C2 – with full grub functionality – at:
This used a two-stage loading of grub, with the first grub.cfg – that was able to be ‘found’ OK by U-Boot – acting as a pointer to the location of the ‘real’ grub.cfg, with the kernel menu etc., and then to load that.
To get this to work with the C2 and Fedora, I used the Fedora Pi3 image (which included EFI etc) and removed the pi-specific info (cma-256 etc) from the grub configuration.
I then created an interim grub config
/boot/efi/EFI/boot/grub.cfg to point to the Fedora setup, with the following contents:
search --fs-uuid --set=root 9999-9999
– where 9999-9999 should be replaced by the actual UUID of the Fedora EFI partition.
The standard Fedora grub configuration was then loaded from
At last I could see the complete grub kernel menu, but for some reason the system failed to boot each time, but did boot OK after several reboot attempts..
After more research, I found that the mainline version of U-Boot I was using (April 2019) was the culprit. I had tried using the latest (July) version, but that had failed to load anything from an EFI (fat32) partition, so I had reverted to the April version.
I then noticed that OpenSuse had – helpfully – included copies of all the Hardkernel U-Boot components in the root directory of their disk image, so I copied these across and installed them on the C2 eMMC in place of the unreliable April 2019 U-Boot, and after that, everything worked OK.
I use # grub-customizer to update grub for new kernels etc, and have it configured to recognise the C2 serial console UART, which presents as
Fedora 30 (Workstation Edition)
Kernel 5.3.0-rc5 on an aarch64 (ttyAML0)
]# uname -a
Linux rgodroid 5.3.0-rc5 #2 SMP Sun Aug 18 21:41:39 EDT 2019 aarch64 aarch64 aarch64 GNU/Linux
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.3.0-rc5 root=UUID=99999999-9999-9999-9999-9999999999 ro rhgb console=tty0 console=ttyAML0,115200n8 noplymouth net.ifnames=0
The only recurring issue, is that the C2 seems to be somewhat unstable, with frequent kernel faults (also occurring on the released 5.2 kernel):
[ 3.159821] ------------[ cut here ]------------
[ 3.159866] WARNING: CPU: 3 PID: 1080 at drivers/regulator/core.c:2036 _regulator_put.part.0+0xbc/0xc8
[ 3.159868] Modules linked in: dwc2(+) usbcore meson_canvas ipv6 nf_defrag_ipv6
[ 3.159882] CPU: 3 PID: 1080 Comm: systemd-udevd Tainted: G W 5.3.0-rc3 #3
[ 3.159883] Hardware name: amlogic odroid-c2/odroid-c2, BIOS 2019.04 04/09/2019
[ 3.159887] pstate: 40000005 (nZcv daif -PAN -UAO)
Robert Gadsdon. August 19th 2019.