[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-arm
Subject:    Re: Can't install on ROCK64 : tftp not permitted
From:       Mark Kettenis <mark.kettenis () xs4all ! nl>
Date:       2018-12-27 15:12:27
Message-ID: 9e5d000edb346426 () bloch ! sibelius ! xs4all ! nl
[Download RAW message or body]

> Date: Thu, 27 Dec 2018 15:25:56 +0100
> From: Thuban <thuban@yeuxdelibad.net>
> 
> * Thuban <thuban@yeuxdelibad.net> le [27-12-2018 12:27:07 +0100]:
> > Hello,
> > I can't install OpenBSD on my ROCK64. 
> > I see the following error in serial console : 
> > 
> > 	booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
> > 	 failed(1). will try /bsd
> > 
> > 
> > I can't figure out how to solve this even by searching on the list. Any
> > advice please ?
> > 
> > I followed theses steps : 
> > 
> > - Flash SPI with ayufan flash image : 
> > 	https://github.com/ayufan-rock64/linux-u-boot/releases/latest
> > - dd miniroot.fs (6.4) and copy the rk3328-rock64.dtb file as mentioned
> > in install notes
> > - Plus serial console and power up the ROCK64. 
> > 
> > 
> > Here is the whole log, showing rk3328-rock64.dtb is read : 
> > 
> > 
> > 	switch to partitions #0, OK
> > 	mmc1 is current device
> > 	Scanning mmc 1:1...
> > 	reading /rockchip/rk3328-rock64.dtb
> > 	31685 bytes read in 5 ms (6 MiB/s)
> > 	Found EFI removable media binary efi/boot/bootaa64.efi
> > 	reading efi/boot/bootaa64.efi
> > 	116963 bytes read in 10 ms (11.2 MiB/s)
> > 	## Starting EFI application at 02000000 ...
> > 	Scanning disk rksdmmc@ff520000.blk...
> > 	** First descriptor is NOT a primary desc on 0:1 **
> > 	Scanning diFound 2 disks
> > 	>> OpenBSD/arm64 BOOTAA64 0.13
> > 	open(tftp0a:/etc/boot.conf): Operation not permitted
> > 	boot> 
> > 	booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
> > 	 failed(1). will try /bsd
> > 	boot> 
> > 	booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
> > 	 failed(1). will try /bsd
> > 	Turning timeout off.
> > 
> 
> It finally worked with an older version of ayufan uboot. Don't know why
> though.

I've seen this happen with certain (buggy) U-Boot versions that put
random garbage into (unused) parts of the EFI device paths.  As a
result device path component comparison done in the OpenBSD bootloader
fails and the bootloader falls back on using tftp.

I actually have an RK3399 board where the vendor-provided U-Boot has
the same issue, but the issue disappears after some failed boot
attempts.

[prev in list] [next in list] [prev in thread] [next in thread]