I have recently acquired an Odroid N2 (4GB) and managed – with some difficulty – to get it to run a ‘modern’ U-Boot, Kernel 5.6-rc2, with EFI support, and Fedora 31.

Odroid N2

This time, there were no clues from OpenSuse, and all the examples I found still used the ancient/custom Hardkernel u-boot and a kernel.img ‘blob.

Fortunately, the process I had used to get all this working – including the ‘two-stage’ grub – on the Odroid C2, still applied in to this Odroid N2, and this is documented in my previous article here: http://rglinuxtech.com/?p=2595
This time, I was forced to compile a ‘new’ u-boot from scratch, including the Hardkernel binary bits, and this proved a pain, as expected. The latest mainline version of u-boot compiles OK with gcc 9 (Fedora 31) but the proprietary bits need the ancient Hardkernel version of u-boot, which only compiles with a now-obsolete version of gcc 4.   Details of this process are here: https://wiki.odroid.com/odroid-n2/software/building_u-boot .
I had all sorts of odd problems with the compile, and repeated ” error: redefinition of ‘fdt_offset_ptr_” errors, and eventually had to (temporarily) uninstall the F31 version of libfdt-devel to get the compile to work.
The complete instructions to build the hybrid u-boot can be found in the mainline source tree, at ~/u-boot/board/amlogic/w400/README.odroid-n2, and – yes – the instruction to copy the same u-boot.bin.sd.bin file to two different places is correct..

After all was finished, the system booted into 5.6-rc2:

GNU GRUB version 2.02
┌────────────────────────────────────────────────────────────────────────────┐
│*Fedora (5.6.0-rc2) 31 (Workstation Edition) │
│ Fedora (5.6.0-rc1) 31 (Workstation Edition) │
│ Fedora (5.4.19-200.fc31.aarch64) 31 (Workstation Edition) │
│ Fedora (0-rescue-458dfe492c2e4f2e83ddee12c38f36af) 31 (Workstation Edition►│
│ │
└────────────────────────────────────────────────────────────────────────────┘
EFI stub: Booting Linux Kernel…
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map…
Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Linux version 5.6.0-rc2 (root@rgodroidn2) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #2 SMP PREEMPT Sun Feb 16 20:50:26 PST 2020
Machine model: Hardkernel ODROID-N2
efi: Getting EFI parameters from FDT:
efi: EFI v2.80 by Das U-Boot
……………
Fedora 31 (Workstation Edition)
Kernel 5.6.0-rc2 on an aarch64 (ttyAML0)
……………
[root@rgodroidn2 ~]# uname -a
Linux rgodroidn2 5.6.0-rc2 #1 SMP PREEMPT Sun Feb 16 16:45:26 PST 2020 aarch64 aarch64 aarch64 GNU/Linux

The only problem, was that the HDMI had no output. I double-checked that it was not a hardware problem by booting from a CoreElec sdcard, and the display worked OK. The kernel was loading the correct drivers, so it looked like a hardware initialization issue..
….
meson-drm ff900000.vpu: master bind failed: -517
…..
I then found that the u-boot command to load the N2 dtb was not functioning, even though it was in the correct location.. I then stopped the boot process in u-boot, and manually loaded the dtb:
=> load mmc 1:2 0x08008000 /dtb/amlogic/meson-g12b-odroid-n2.dtb
and then
=> boot
– then HDMI worked OK, and the console appeared on the screen.
In the past, I would have changed the u-boot command set to make it work, but this version does not have any ‘saveenv’ capability. After examining the output of => printenv , I copied the dtb from ~/dtb/amlogic/meson-g12b-odroid-n2.dtb to ~/amlogic/meson-g12b-odroid-n2.dtb, and then the HDMI was recognised correctly, until it just stopped working again.. I found that continued reboots would sometimes recognise the dtb, and sometimes not.. This may be another example of an unreliable version of u-boot, which is what happened with my tests for the Odroid C2..

To fix this, I created a one-line boot.scr in /boot/efi, with:
load mmc 1:2 0x08008000 /dtb/amlogic/meson-g12b-odroid-n2.dtb

When HDMI worked, I tried to get some sort of graphical output, and found that KDE/Plasma/Wayland actually worked quite well, apart from video playback – as expected – not being very smooth. The panfrost kernel drivers are in 5.6-rc, and hopefully this will improve with better userland Wayland support in time…

Robert Gadsdon.   February 17th 2020