GW6304 u-boot openbsd

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GW6304 u-boot openbsd

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
<stdout>: Warning (unit_address_vs_reg): /images/kernel@1: node has a
unit name, but no reg property
<stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node
has a unit name, but no reg property
<stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node
has a unit name, but no reg property
<stdout>: 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: 0x20080000
  Entry Point:  0x20080000
  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 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?

Thanks,

Jamie.




Reply | Threaded
Open this post in threaded view
|

Re: GW6304 u-boot openbsd

Patrick Wildt-2
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 <[hidden email]>:
>
> 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
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1: node has a
> unit name, but no reg property
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node
> has a unit name, but no reg property
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node
> has a unit name, but no reg property
> <stdout>: 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: 0x20080000
>  Entry Point:  0x20080000
>  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 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?
>
> Thanks,
>
> Jamie.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: GW6304 u-boot openbsd

Jonathan Gray-11
In reply to this post by Jamie
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
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1: node has a
> unit name, but no reg property
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@1: node
> has a unit name, but no reg property
> <stdout>: Warning (unit_address_vs_reg): /images/kernel@1/hash@2: node
> has a unit name, but no reg property
> <stdout>: 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: 0x20080000
>   Entry Point:  0x20080000
>   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 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.

Reply | Threaded
Open this post in threaded view
|

Re: GW6304 u-boot openbsd

Jamie
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!

Thanks again,

Jamie.



Reply | Threaded
Open this post in threaded view
|

Re: GW6304 u-boot openbsd

Mark Kettenis
> From: Jamie <[hidden email]>
> 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!

Reply | Threaded
Open this post in threaded view
|

Re: GW6304 u-boot openbsd

Jamie
On Sat, 2019-03-23 at 15:26 +0100, Mark Kettenis wrote:

> > From: Jamie <[hidden email]>
> > 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 (000000007aec17a0)
   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 02000000 ...
   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 02000000 ...
   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.