GW6304 u-boot openbsd
Hi! Quite new to OpenBSD on ARM64 and, while I have a Gateworks newport GW6304 running Linux, I'm keen to get OpenBSD running on it and was hoping for a little nudge. Following INSTALL.arm64, I wrote the miniroot64.fs to a microSD card then added the vendor (cavium) dtb to the first partition but obviously it didn't boot (which isn't that surprising I guess). I then boot the working "linux" firmware to u-boot and tried a variety of manual loads (following the OcteonTX SDK) of the binaries from the vfat partition but no joy. Using the approach that built the Linux bootable image I then attempted to adapt it for OpenBSD to create a 'bsd.its' for u-boot (just to see if I could get the kernel loading) via: mkits.sh -o bsd.its -k bsd.gz -C gzip -v 'openbsd64' mkimage -f bsd.its bsd.itb : Warning (unit_address_vs_reg): /images/kernel@1: node has a unit name, but no reg property : Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node has a unit name, but no reg property : Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node has a unit name, but no reg property : Warning (unit_address_vs_reg): /configurations/config@1: node has a unit name, but no reg property FIT description: ARM64 FIT (Flattened Image Tree) Created: Sat Mar 23 18:03:35 2019 Image 0 (kernel@1) Description: ARM64 openbsd64 Created: Sat Mar 23 18:03:35 2019 Type: Kernel Image Compression: gzip compressed Data Size:4147385 Bytes = 4050.18 KiB = 3.96 MiB Architecture: AArch64 OS: OpenBSD Load Address: 0x2008 Entry Point: 0x2008 Hash algo:crc32 Hash value: 630cb6b4 Hash algo:sha1 Hash value: 29b3f3d20aad3d8829faf13a81edcfdb0fa357ac Default Configuration: 'config@1' Configuration 0 (config@1) Description: Boot OpenBSD Kernel Kernel: kernel@1 FDT: fdt@1 I then try to simply boot that kernel via: GW6304-D2>fatload mmc 1:1 $loadaddr bsd.itb GW6304-D2>bootm $loadaddr ## Loading kernel from FIT Image at 0200 ... 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: 0x02d4 Data Size:4147385 Bytes = 4 MiB Architecture: AArch64 OS: Unknown OS Load Address: 0x2008 Entry Point: 0x2008 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? Thanks, Jamie.
Re: GW6304 u-boot openbsd
We rely on U-Boot‘s EFI support. So if the GW‘s U-Boot supports the „bootefi“ command there‘s a chance, otherwise not. :) Von meinem iPhone gesendet > Am 23.03.2019 um 09:01 schrieb Jamie : > > Hi! > > Quite new to OpenBSD on ARM64 and, while I have a Gateworks newport > GW6304 running Linux, I'm keen to get OpenBSD running on it and was > hoping for a little nudge. > > Following INSTALL.arm64, I wrote the miniroot64.fs to a microSD card > then added the vendor (cavium) dtb to the first partition but obviously > it didn't boot (which isn't that surprising I guess). I then boot the > working "linux" firmware to u-boot and tried a variety of manual loads > (following the OcteonTX SDK) of the binaries from the vfat partition > but no joy. > > Using the approach that built the Linux bootable image I then attempted > to adapt it for OpenBSD to create a 'bsd.its' for u-boot (just to see > if I could get the kernel loading) via: > > mkits.sh -o bsd.its -k bsd.gz -C gzip -v 'openbsd64' > mkimage -f bsd.its bsd.itb > : Warning (unit_address_vs_reg): /images/kernel@1: node has a > unit name, but no reg property > : Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node > has a unit name, but no reg property > : Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node > has a unit name, but no reg property > : Warning (unit_address_vs_reg): /configurations/config@1: node > has a unit name, but no reg property > FIT description: ARM64 FIT (Flattened Image Tree) > Created: Sat Mar 23 18:03:35 2019 > Image 0 (kernel@1) > Description: ARM64 openbsd64 > Created: Sat Mar 23 18:03:35 2019 > Type: Kernel Image > Compression: gzip compressed > Data Size:4147385 Bytes = 4050.18 KiB = 3.96 MiB > Architecture: AArch64 > OS: OpenBSD > Load Address: 0x2008 > Entry Point: 0x2008 > Hash algo:crc32 > Hash value: 630cb6b4 > Hash algo:sha1 > Hash value: 29b3f3d20aad3d8829faf13a81edcfdb0fa357ac > Default Configuration: 'config@1' > Configuration 0 (config@1) > Description: Boot OpenBSD Kernel > Kernel: kernel@1 > FDT: fdt@1 > > I then try to simply boot that kernel via: > > GW6304-D2>fatload mmc 1:1 $loadaddr bsd.itb > GW6304-D2>bootm $loadaddr > ## Loading kernel from FIT Image at 0200 ... > 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: 0x02d4 > Data Size:4147385 Bytes = 4 MiB > Architecture: AArch64 > OS: Unknown OS > Load Address: 0x2008 > Entry Point: 0x2008 > 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? > > Thanks, > > Jamie. > > > >
Re: GW6304 u-boot openbsd
On Sat, Mar 23, 2019 at 07:01:44PM +1100, Jamie wrote: > Hi! > > Quite new to OpenBSD on ARM64 and, while I have a Gateworks newport > GW6304 running Linux, I'm keen to get OpenBSD running on it and was > hoping for a little nudge. > > Following INSTALL.arm64, I wrote the miniroot64.fs to a microSD card > then added the vendor (cavium) dtb to the first partition but obviously > it didn't boot (which isn't that surprising I guess). I then boot the > working "linux" firmware to u-boot and tried a variety of manual loads > (following the OcteonTX SDK) of the binaries from the vfat partition > but no joy. > > Using the approach that built the Linux bootable image I then attempted > to adapt it for OpenBSD to create a 'bsd.its' for u-boot (just to see > if I could get the kernel loading) via: > > mkits.sh -o bsd.its -k bsd.gz -C gzip -v 'openbsd64' > mkimage -f bsd.its bsd.itb > : Warning (unit_address_vs_reg): /images/kernel@1: node has a > unit name, but no reg property > : Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node > has a unit name, but no reg property > : Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node > has a unit name, but no reg property > : Warning (unit_address_vs_reg): /configurations/config@1: node > has a unit name, but no reg property > FIT description: ARM64 FIT (Flattened Image Tree) > Created: Sat Mar 23 18:03:35 2019 > Image 0 (kernel@1) > Description: ARM64 openbsd64 > Created: Sat Mar 23 18:03:35 2019 > Type: Kernel Image > Compression: gzip compressed > Data Size:4147385 Bytes = 4050.18 KiB = 3.96 MiB > Architecture: AArch64 > OS: OpenBSD > Load Address: 0x2008 > Entry Point: 0x2008 > Hash algo:crc32 > Hash value: 630cb6b4 > Hash algo:sha1 > Hash value: 29b3f3d20aad3d8829faf13a81edcfdb0fa357ac > Default Configuration: 'config@1' > Configuration 0 (config@1) > Description: Boot OpenBSD Kernel > Kernel: kernel@1 > FDT: fdt@1 > > I then try to simply boot that kernel via: > > GW6304-D2>fatload mmc 1:1 $loadaddr bsd.itb > GW6304-D2>bootm $loadaddr > ## Loading kernel from FIT Image at 0200 ... >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: 0x02d4 > Data Size:4147385 Bytes = 4 MiB > Architecture: AArch64 > OS: Unknown OS > Load Address: 0x2008 > Entry Point: 0x2008 > 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.
Re: GW6304 u-boot openbsd
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 0200 ... > >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: 0x02d4 > > Data Size:4147385 Bytes = 4 MiB > > Architecture: AArch64 > > OS: Unknown OS > > Load Address: 0x2008 > > Entry Point: 0x2008 > > 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! Thanks again, Jamie.
Re: GW6304 u-boot openbsd
> From: Jamie > 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 0200 ... > > >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: 0x02d4 > > > Data Size:4147385 Bytes = 4 MiB > > > Architecture: AArch64 > > > OS: Unknown OS > > > Load Address: 0x2008 > > > Entry Point: 0x2008 > > > 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!
Re: GW6304 u-boot openbsd
On Sat, 2019-03-23 at 15:26 +0100, Mark Kettenis wrote: > > From: Jamie > > Date: Sat, 23 Mar 2019 22:04:44 +1100 > > > > [snipped] > > > > 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 default on the > x2018.11-newport-rc1 branch, so no further patching would be > necessary. I did have a quick try at building the 2018.11 variant however it failed to build at: make CROSS_COMPILE= -C u-boot env make[2]: Entering directory '/home/tango/research/cavium/octeontx/test1/u-boot' CHK include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s cc1: warning: unknown register name: x18 cc1: error: bad value (‘armv8-a’) for ‘-march=’ switch I was able to successfully build and boot the older version with, essentially, that patch reverted and that did provide a 'bootefi' command however wonder if the build isn't quite right yet. GW6304-D2> load mmc 1:1 $fdtcontroladdr gw6304-linux.dtb reading gw6304-linux.dtb FAT: Misaligned buffer address (7aec17a0) 18201 bytes read in 16 ms (1.1 MiB/s) GW6304-D2> load mmc 1:1 $kernel_addr_r efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 116963 bytes read in 13 ms (8.6 MiB/s) GW6304-D2> GW6304-D2> bootefi $kernel_addr_r $fdtcontroladdr ## Starting EFI application at 0200 ... ERROR: FDT BDK node not found ERROR: board-specific fdt fixup failed: FDT_ERR_NOTFOUND - must RESET the board to recover. ERROR: Failed to process device tree ## Application terminated, r = 9223372036854775786 I did try booting without the DTB just to see how far it got but I guess, at least, it got to the boot> prompt. GW6304-D2> load mmc 1:1 $kernel_addr_r efi/boot/bootaa64.efi GW6304-D2> bootefi $kernel_addr_r ## Starting EFI application at 0200 ... WARNING: Invalid device tree, expect boot to fail Scanning disk mmc@1,4.blk... Scanning disk mmc@1,4.blk... Found 2 disks >> OpenBSD/arm64 BOOTAA64 0.13 no OpenBSD MBR partition open(sd0a:/etc/boot.conf): Invalid argument boot> no OpenBSD MBR partition cannot open sd0a:/etc/random.seed: Invalid argument booting sd0a:/bsd: no OpenBSD MBR partition open sd0a:/bsd: Invalid argument failed(22). will try /bsd boot> I'll have a think and look at it again later, Jamie.
