OK, those of you that have been waiting, rip away!
I've been trying to get the ODROID H2 here to boot OpenWrt quite unsuccessfully. It runs Debian 10 quite well from an SSD in a USB3 enclosure, or direct connected. When I flash the current snapshot, either ext4 or squashfs (sha256 sum confirmed), to a SSD and either put in the same enclosure or attach it directly, the BIOS doesn't recognize it as bootable.
I can mount both partition 1 ("boot") and partition 2 (root) on a Debian 10 system, at least for the ext4 file system.
Any ideas what to try next?
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sha256sum openwrt-x86-64-combined-ext4.img.gz
eed3f3cc3add9bf4ae9364953c5a34a6a033a43a056f5772edeed9dc14955e6f openwrt-x86-64-combined-ext4.img.gz
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ zcat openwrt-x86-64-combined-ext4.img.gz | sudo dd of=/dev/sdd bs=1M
[sudo] password for jeff:
0+4622 records in
0+4622 records out
151519232 bytes (152 MB, 144 MiB) copied, 1.19399 s, 127 MB/s
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo mount /dev/sdd1 /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ ls /mnt
boot lost+found
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo umount /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo mount /dev/sdd2 /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ ls /mnt
bin dev etc lib lib64 lost+found mnt overlay proc rom root sbin sys tmp usr var www
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo umount /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sync
AMI BIOS, 2.19.1268 gets entered, no boot-device options are shown in the menu. Never gets to the kernel.
I'd probably first test setting CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y in target/linux/x86/64/config-*
Given that you have Debian running on that device, it might also help to check if maybe UEFI is running in 32 bit mode, in which case you might need CONFIG_EFI_MIXED=y (and more work on the grub side).
No idea if this sill applies for UEFI, but - I have an Odroid XU4 running Debian as well, and I had to remember to toggle the boot flag on the /boot partition. Maybe something similar here?
That shouldn't be an issue (famous last words), for UEFI all what matters is GPT partitioning with a FAT32 partition labelled as EF00 (EFI System Partition); although really weird UEFI implementations might look at the protective MBR…
(and yes, having to set a bootflag was/ is one of the most braindead traits of some BIOS implementations)
/sbin/fdisk --type dos <openwrt_image> would allow setting a boot flag on the protective MBR for the GPT partition (it's needed for some systems with a (broken) legacy BIOS to accept GPT for booting, it shouldn't matter for UEFI).
UEFI by default only has drivers to read from FAT32 filesystems. OpenWrt makes 2 ext2/4 partitions. It won't work.
Apart from that, UEFI can't boot the kernel unless you are also compiling in efi stub in the kernel (so it becomes a EFI executable and can be loaded and executed, or you are using a EFI bootloader that does the booting (i.e. GRUB UEFI).
So again it won't work even if it could read the boot partition, as OpenWrt is not using GRUB EFI.
Since the firmware on that board does not have the CSM feature/module, you can't just boot it in legacy/BIOS mode.
Since apparently no core dev is giving a shit about UEFI support
(the PR https://github.com/openwrt/openwrt/pull/1968 has been sitting there for ages, and it's the last one of a list, the first appeared in LEDE days),
you either compile your firmware using that, or just use Debian (or VyOS, a network-oriented Debian dderivative) and be done with it.
Yes, it will be running FreeBSD, but I thought I'd benchmark it under OpenWrt with all the interest in "cheap" solutions for gigabit lines.
The PR seems to get some things right, but I'm still tempted to go with a from-scratch solution with an EFI-enabled kernel and a root file system, at least until I can get it to boot once.
GNU Parted 3.2
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK
Warning: Not all of the space available to /dev/sdd appears to be used, you can fix the GPT to use all of the space (an extra 234145649 blocks) or continue with
the current setting?
Fix/Ignore? i
Model: Inateck (scsi)
Disk /dev/sdd: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
128 17.4kB 262kB 245kB bios_grub
1 262kB 17.0MB 16.8MB fat16 EFI System Partition boot, esp
2 17.3MB 152MB 134MB ext2 msftdata
That error is expected and explained in the commit.
Since the image building process has to be generic they can't create the backup GPT table.
GPT has two partition tables, one at the start and one at the end of the drive. They just can't know the size of your drive when they generate the image, so they just add some padding at the end, but no partition table.
Similar for the "not all of the space available appears to be used" error. They can't know what is the size of the drive you will have so they just set a high enough capacity.
The system works fine with just one table and you can fix that error by just opening that in fdisk (a GPT-aware one) or gdisk, and then write to disk.
@markbirss As noted on the other thread that link was posted to, and now edited on that wiki page, the referenced branch in jow's repo doesn't exist. The two commits that differ between that repo and master and seem related to UEFI date back to early 2017 and were never accepted by OpenWrt.
Edit: Able to get boot with https://github.com/openwrt/openwrt/pull/1968 as linked by slh and bobafetthotmail. With no console it's hard to figure out quite what is going on, but when I narrow things down, I'll try to clarify just what made the change. For now, rebasing the branch from the PR (not from the wiki page) onto one of your choice seems a reasonable approach.
Edit: On the ODRIOD H2 in the default OpenWrt config, the "LAN" port (eth0) is the one above the USB2 ports, the "WAN" port (eth1) is the one above the USB3 ports.
Both, unfortunately. I see the AMI splash when it boots, then just an underline when I'd normally expect to see the kernel boot sequence. On the serial, I haven't yet been successful with https://wiki.odroid.com/odroid-h2/hardware/2x10gpio in getting a kernel console (though can run ttyS0 and ttyS1 from userspace). The grub config looked as though it should enable the serial.
Since it's booting now, I'm running the tests to answer a question on one of the gigabit-router threads, then may go back to figuring out what's going on with the video and serial consoles.