Re: port-sparc64/54719: sparc64 fails to boot since switch to gcc8

[Mark Cave-Ayland <mark.cave-ayland%ilande.co.uk@localhost>]

The following reply was made to PR port-sparc64/54719; it has been noted by GNATS.

From: Mark Cave-Ayland <mark.cave-ayland%ilande.co.uk@localhost>
To: Martin Husemann <martin%duskware.de@localhost>, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-sparc64/54719: sparc64 fails to boot since switch to gcc8
Date: Mon, 25 Nov 2019 20:52:15 +0000

 On 25/11/2019 15:19, Martin Husemann wrote:
 
 > On Mon, Nov 25, 2019 at 02:10:00PM +0000, Andreas Gustafsson wrote:
 >>> Number:         54719
 >>> Category:       port-sparc64
 >>> Synopsis:       sparc64 fails to boot since switch to gcc8
 >>   Welcome to OpenBIOS v1.1 built on Jul 1 2019 17:08
 >>     Type 'help' for detailed information
 >>   Trying cdrom:f...
 >>   Not a bootable ELF image
 >>   Not a bootable a.out image
 >>
 >>   Loading FCode image...
 >>   Loaded 7514 bytes
 >>   entry point is 0x4000
 >>   Evaluating FCode...
 >>   NetBSD IEEE 1275 Multi-FS Bootblock
 >>   Version $NetBSD: bootblk.fth,v 1.15 2015/08/20 05:40:08 dholland Exp $
 >>   ..Unhandled Exception 0x0000000000000030
 >>   PC = 0x00000000ffd0f2b8 NPC = 0x00000000ffd0f2bc
 >>   Stopping execution
 >>
 >> This does not affect sparc, only sparc64.
 > 
 > FWIW: it works fine on real hardware (with OpenFirmware).
 > 
 > Mark, could you have a look and tell us what firmware call goes wrong and
 > what its args are?
 > 
 > Should be enough to boot the sparc64 HEAD iso image (from 
 > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.18-sparc64.iso)
 > in qemu.
 > 
 > Thanks!
 > 
 > Martin
 
 Hi Martin,
 
 After a fun few hours trying to debug this, I've managed to figure out what's going
 on and it's related to the way in which OpenBIOS switches contexts.
 
 What is happening is that right at the end of the FCode compiled from bootblk.fth we
 run do-boot which loads /ofwboot into RAM and then executes "init-program" to set the
 saved state context, which in OpenBIOS is implemented on a context stack.
 
 The problem is that once "init-program" returns after setting the saved stack
 context, OpenBIOS then pops off the previous context which was executing the FCode
 before switching to the new one. Unfortunately bootblk.fth, just like the FCode
 before it, uses the memory at load-base  which means that instead of returning back
 to the FCode to read the final end0 (0x0) byte to terminate the interpreter, instead
 we start trying to execute the contents of ofwboot as FCode...
 
 Comparing with previous NetBSD versions it seems that with those we just got lucky
 and hit a 0x0 byte before too long, switched context to ofwboot and everything worked
 fine. With a gcc-8 compiled ofwboot from the latest HEAD ISO it seems we hit a 0x90
 "type" token which pulls a bogus address from the stack and then crashes.
 
 Ultimately it makes sense for OpenBIOS to not use a context stack for launching
 client program contexts and instead use a single fixed context since this is
 evidently what OBP does - but that's going to take a bit of time to fix.
 
 The quickest solution I can think of for now is if you can use a special linker
 script for ofwboot to place the first section starting at offset 0x2000 in the ELF
 binary after the first 8k page - since the offending byte is at offset 0x1d58 then
 this temporarily ensures that when returning from "init-program" then we hit a zero
 byte which should allow the context switch to succeed.
 
 
 ATB,
 
 Mark.