Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> wrote: > On 30/05/2020 00:19, Jason A. Donenfeld wrote: > > > Note that you need to run this with `-nographic`, because the kernel > > crashes when trying to use vgafb on sparc64/qemu. I've witnessed two > > varieties crashes: > > > > - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png > > This happens when booting up miniroot67.fs > > > > - > > https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-after-installation.png > > This happens after installation openbsd onto disk properly, and then > > booting up into it. > > > > Passing `-nographic` prevents these from happening, since vgafb doesn't > > bind to anything. > > > > I don't have a bsd.gdb in order to addr2line this, but if the miniroot > > panic is related to the normal panic, and we then assume alignment > > issues in fb_get_console_metrics, then I wonder if the below patch would > > make a difference. On the other hand, a "data access fault" makes it > > seem more likely that OF_interpret is just getting bogus addresses from > > buggy qemu firmware. > > > > I probably have another two hours to go in waiting for this thing to > > build... > > > > Jason > > > > --- a/sys/arch/sparc64/dev/fb.c > > +++ b/sys/arch/sparc64/dev/fb.c > > @@ -507,6 +507,7 @@ int > > fb_get_console_metrics(int *fontwidth, int *fontheight, int *wtop, int > > *wleft) > > { > > cell_t romheight, romwidth, windowtop, windowleft; > > + uint64_t romheight_64, romwidth_64, windowtop_64, windowleft_64; > > > > /* > > * Get the PROM font metrics and address > > @@ -520,10 +521,15 @@ fb_get_console_metrics(int *fontwidth, int > > *fontheight, int *wtop, int *wleft) > > windowtop == 0 || windowleft == 0) > > return (1); > > > > - *fontwidth = (int)*(uint64_t *)romwidth; > > - *fontheight = (int)*(uint64_t *)romheight; > > - *wtop = (int)*(uint64_t *)windowtop; > > - *wleft = (int)*(uint64_t *)windowleft; > > + memcpy(&romheight_64, (void *)romheight, sizeof(romheight_64)); > > + memcpy(&romwidth_64, (void *)romwidth, sizeof(romwidth_64)); > > + memcpy(&windowtop_64, (void *)windowtop, sizeof(windowtop_64)); > > + memcpy(&windowleft_64, (void *)windowleft, sizeof(windowleft_64)); > > + > > + *fontwidth = (int)romwidth_64; > > + *fontheight = (int)romheight_64; > > + *wtop = (int)windowtop_64; > > + *wleft = (int)windowleft_64; > > > > return (0); > > } > > AFAICT the problem here is the Forth being used at > https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: > since the > addr word isn't part of the IEEE-1275 specification, it is currently > unimplemented in > OpenBIOS. > > Why is addr needed here? Does the fb.c driver try and change these values > rather than > just read them?
Why does that matter? sparc64 isn't a IEEE-1275 openfirmware. It is a Sun openfirmware, meaning it is more than the vague specification. An emulation must be able to emulate THE REAL HARDWARE. This should work. For another 64-bit cell_t usage see dev/prtc.c. For another "addr" usage, see romgetcursoraddr()
