Re: slot-based crash! not SBusFPGA (Re: CG14 in 8-bit color)

Le mer. 12 janv. 2022 à 18:07, David Brownlee <[email protected]> a écrit :
> That's a little wild (though congratulations on finally finding it!)

Yeah it's weird. A bit of luck was involved; I ended up trying to
reproduce a real cg6 even more, and moving slots was really just to be
thorough, I really didn't expect it to do anything.

> I wonder what specific usage is triggering the issue

Me too, I have honestly no idea of even (a) possible reason(s), let
alone the real one(s).

> - Known hardware issue: Could slot 1 not be certified for
> framebuffers?

Possibly, but as far I know slots in the SS20 are supposed to be
identical. The only irregularity I remember is slot 3 in the 3-slots
pizzabox (SS1, SS2) which is slave-only. And Sun would recommend
putting the framebuffer there as framebuffers are slave-only devices,
whereas other common SBus cards (Ethernet, SCSI, even high-speed
serials) are bus masters.

> - Software issue: Does SunOS/Solaris on the box show the issue (in
> case its a usage pattern that only NetBSD triggers)

Haven't tried either yet; I could try with either bw2 or cg3 - I
suspect my cg6 emulation is nowhere near complete enough for
period-accurate operating systems.
The problem with SunOS/Solaris is that whereas they can use my dumb
framebuffer emulation, neither will be able to use any of the other
devices (USB, micro-sd, RAM disk). That's why I've stayed with NetBSD
only so far.

> - Specific trigger: It might be possible to run as a cg3 and "do less"
> to see what is the minimum to trigger

As far as I can tell, 'minimum trigger' is X11 + swap. I don't
remember a crash under other circumstances. But I didn't try a lot of
different things, either.
And with just the cg3 emulation, X11 is pretty much only writing
through SBus to the framebuffer (and maybe reading for
read-modify-write, and maybe not even reading if the SW uses byte
accesses) so there's little opportunity to mess up - unlike the cg6
emulation where theoretically the VexRiscv core could inadvertently
write to some random DVMA address and mess up other devices.

I haven't really had time to figure out the issue. I probably should
try in another SS20 first, and if it works in Slot 1 there, I have my
answer. If not, then I will need to find more time.
But then on my 'todo' list, I also need to do a 8/24 FB with some
acceleration, probably inspired by Michael's work on the SX, which is
going to take time. Then think about another update to the carrier to
get a proper video output (FPGA are OK at doing HDMI), but my current
design will run out of pins - so with a different FPGA daughterboard
as well... that project is an endless waste of time and money :-)

So in the meantime I've found another way to waste time and money -
I'm considering re-using the same FPGA daughterboard for a NuBus
carrier for old Macs, where I could prototype the VGA and/or HDMI
output (old 68k Macs are worse than SPARCstation when it comes to
video output, at least the TGX+ and SX can do 1280x1024 and use 17"
and 19" LCDs at native resolution, 68k Macs are stuck at 1152x870 at
best and often at 1024x768 or even 832x624 or 640x480). The nice thing
is that theoretically, I could get the same X11 acceleration in both
NetBSD/mac68k and NetBSD/sparc eventually (should I manage to install
a working NetBSD on my Quadra 650, primary target for NuBusFPGA is
good old System 7 / MacOS 8 at first).

Of course the NuBus work would be even more useful if NetBSD/macppc
supported the NuBus-based Power Macintoshes :-)

Cordially,

-- 
Romain Dolbeau