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.
