> From: Jamie <ja...@hush.com> > Date: Sat, 23 Mar 2019 22:04:44 +1100 > > On Sat, 2019-03-23 at 20:34 +1100, Jonathan Gray wrote: > > On Sat, Mar 23, 2019 at 07:01:44PM +1100, Jamie wrote: > > > Hi! > > > [ snipped ] > > > GW6304-D2>fatload mmc 1:1 $loadaddr bsd.itb > > > GW6304-D2>bootm $loadaddr > > > ## Loading kernel from FIT Image at 02000000 ... > > > Using 'config@1' configuration > > > Verifying Hash Integrity ... OK > > > Trying 'kernel@1' kernel subimage > > > Description: ARM64 openbsd64 > > > Created: 2019-03-23 6:17:14 UTC > > > Type: Kernel Image > > > Compression: gzip compressed > > > Data Start: 0x020000d4 > > > Data Size: 4147385 Bytes = 4 MiB > > > Architecture: AArch64 > > > OS: Unknown OS > > > Load Address: 0x20080000 > > > Entry Point: 0x20080000 > > > Hash algo: crc32 > > > Hash value: 630cb6b4 > > > Hash algo: sha1 > > > Hash value: 29b3f3d20aad3d8829faf13a81edcfdb0fa357ac > > > Verifying Hash Integrity ... crc32+ sha1+ OK > > > No Unknown OS AArch64 Kernel Image Image > > > ERROR: can't get kernel image! > > > > > > [ I'm wondering why I'm getting 'Unknown OS' when it was written as > > > OpenBSD - perhaps the gateworks u-boot was built without support > > > for non-Linux OSes (https://github.com/Gateworks/manifest-newport) > > > ] > > > > > > Anyway, any thoughts on this approach or should I be trying > > > something else like a TFTP boot? > > > > You can't jump directly to a kernel like that. When U-Boot is built > > with distro boot support it would automatically load bootaa64.efi > > which is on the fat partition in the miniroot. Otherwise you need > > to use the U-Boot 'bootefi' command assuming the vendor U-Boot > > fork you are using has it. > > Thanks both. As you may have guessed the current U-Boot on there > doesn't support bootefi which is why I was looking at the other > 'options'. Naively, I'll go look and see if I can rebuild U-boot with > that command!
Might be a simple matter of reverting: https://github.com/Gateworks/uboot-newport/commit/7de21cea0a97a0d7931adafe69e91bd08b98f2 Why they didn't revert that after Andreas Graf's comment escapes me. You might be better off trying to using the v2018.11-newport-rc1 branch instead of the v2017.09-rc1-newport branch, as the the original U-Boot v2017.09 has a subtle bug that sometimes prevents loading the OpenBSD kernel from the OpenBSD EFI bootloader. I believe that EFI_LOADER support is enabled by defau;lt on the x2018.11-newport-rc1 branch, so no further patching would be necessary. Somebody from Gateworks recently posted patches on the U-Boot developers mailing list, so those boards may end up being supported by mainline U-Boot at some point. I'm interested in making OpenBSD/arm64 work on these boards, and just happened to look at what's currently missing to support the ThunderX SoCs in OpenBSD. So if you get any further let us know! If somebody would be able to donate a development board like this, that would really help!
