On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote:
> On 30/05/2020 10:54, Otto Moerbeek wrote:
>
> > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/
> > contains the unpatched miniroot.
> >
> > https://www.drijf.net/openbsd/disk.qcow2
> >
> > is the disk image based on the miniroot containing the patch in the
> > firts post in this thread.
> >
> > Thanks for looking into this.
> >
> > Note that we did *not* observe boot failure on any real sparc64
> > hardware. The bootblock changes I did for the 6.7 release were tested
> > on many different machines.
>
> Thanks for the test case which enables me to reproduce the issue. With
> ?fcode-verbose
> enabled you see this at the end of the FCode execution:
>
> ...
> ...
> 5acf : [ 0x8b7 ]
> 5ad0 : b(lit) [ 0x10 ]
> 5ad6 : [ 0x81e ]
> 5ad7 : 0= [ 0x34 ]
> 5ad8 : swap [ 0x49 ]
> 5ad9 : drop [ 0x46 ]
> 5ada : b?branch [ 0x14 ]
> (offset) 5
> 5ade : (compile) [ 0x8c8 ]
> 5adf : (compile) b(>resolve) [ 0xb2 ]
> OpenBSD IEEE 1275 Bootblock 2.0
> Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@1/cdrom@0
> Try superblock read
> FFS v1
> ufs-open complete
> .Looking for ofwboot in directory...
> .
> ..
> ofwboot
> Found it
> .Loading 1a1c8 bytes of file...
> Copying 2000 bytes to 4000
> Copying 2000 bytes to 6000
> Copying 2000 bytes to 8000
> Copying 2000 bytes to a000
> Copying 2000 bytes to c000
> Copying 2000 bytes to e000
> Copying 2000 bytes to 10000
> Copying 2000 bytes to 12000
> Copying 2000 bytes to 14000
> Copying 2000 bytes to 16000
> Copying 2000 bytes to 18000
> Copying 2000 bytes to 1a000
> Copying 2000 bytes to 1c000
> Copying 2000 bytes to 1e000
> 5ae0 : expect [ 0x8a ]
>
>
> Now that 0x8a is completely wrong since according to
> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/stand/bootblk/bootblk.fth
> the last instruction should be exit which is 0x33.
>
> Since the FCode itself is located at load-base (0x4000) it looks to me from
> the above
> debug that you're loading ofwboot at the same address, overwriting the FCode.
> Once
> do-boot has finished executing, the FCode interpreter returns to execute the
> exit
> word which has now been overwritten: so instead of returning to the updated
> client
> context via exit to execute ofwboot, it executes expect which asks for input
> from the
> keyboard and then crashes because the stack is incorrect.
>
> My recommendation would be to load ofwboot at 0x6000 instead of 0x4000 which I
> believe will fix the issue. It's interesting you mention that this works on
> real
> hardware, since it doesn't agree with my reading of the IEEE-1275
> specification so
> you're certainly relying on some undocumented behaviour here.
>
>
> ATB,
>
> Mark.
Thanks, the following works indeed.
-Otto
Index: bootblk.fth
===================================================================
RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v
retrieving revision 1.9
diff -u -p -r1.9 bootblk.fth
--- bootblk.fth 2 Apr 2020 06:06:22 -0000 1.9
+++ bootblk.fth 31 May 2020 13:17:25 -0000
@@ -716,7 +716,8 @@ create cur-blockno -1 l, -1 l, \ Curren
2drop
;
-" load-base " evaluate constant loader-base
+\\ Do not overwrite bootblocks
+" load-base " evaluate 2000 + constant loader-base
: load-file-signon ( load-file len boot-path len -- load-file len boot-path
len )
." Loading file" space 2over type cr ." from device" space 2dup type cr
