Re: Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 6, 2024, at 8:07 PM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
> thorpej@ wrote on port-m68k:
> https://mail-index.netbsd.org/port-m68k/2024/01/06/msg000845.html
> 
>>> I guess we can simply change PGSHIFT to 13, but I wonder we should
>>> also consider again to reorganize 040 pmap to make it possible to
>>> expand L2 STEs on demend, as mhitch@ mentioned back in 2009:
>>> https://mail-index.netbsd.org/port-m68k/2009/05/12/msg000143.html
>>> 
>>> Maybe we also have to consider about 3-level pmap like sun3x..
>>> https://mail-index.netbsd.org/port-m68k/2001/07/20/0003.html
>> 
>> That's an idea, but that won't work for the HP MMU on the 320 / 350.
> 
> I should have asked this earlier, but now is the good timing:
> "I'm considering dropping support of (at least) HP320 and HP318/319/330"

Boo :-(  I mean, I regret getting rid of my (pretty stacked) 9000/380 many years ago, but there was a time I had easy access to 319, 320, and 350 models, although, alas, I did not own them.

> The reason why is it looks memory bus design of these hardware
> don't support CAS instruction.

I need to go back and re-read the signal description in the 68020 manual, I guess.  But, yah, the r/m/w instructions do assert a “lock” signal, I think.

> Recently (back in 2022) I have acquired HP319 and HP320
> (as hp300 maintainer) and tried NetBSD 9.3.
> However both machine panicked by bus error on CAS instructions
> in mutex_enter(9) during early boot:

[ ROOTROM Rev. C boot message elided… ]

> NetBSD/hp300 5.0 also fails in mutex_enter(9).
> NetBSD/hp300 4.0.1 boots:
> https://dmesgd.nycbug.org/index.cgi?do=view&id=6786
> 
> (The late) ryo@ commented that he also saw the similar bus errors
> on CAS/TAS instructions on his X68000 with 3rd party expansion RAM
> that didn't support read-modified-write cycle.
> 
> I'm afraid HP320 and HP330 (also 318/319) have the similar hardware
> design, because SMP was unlikely yet in 1980s.
> (though it looks Sun 3/60 bus supports CAS properly)

Yah, it’s certainly possible that none of the 68020 HPs support it.  318 and 319 were basically 320s, and the 350 was, IIRC, a 320 + an external cache.  330 had the PMMU, so maybe it worked differently?

> I tried to build a kernel without CAS but using RAS for sun2/m68010
> implementation, it booted to multiuser on HP320:
> https://twitter.com/tsutsuii/status/1597909609205104640

I think we should do some indirection there to support those models using RAS.  Perhaps I’m just nostalgic (or a luddite :-), but I think so long as the burden isn’t too great, we should try to keep these machines running.

> (BTW, it looks HP98543 topcat seems to have VRAM only at even addresses
> so we need more work in rasops(9) (as 4-depth in 16-bpp?) to support
> it properly)

Perhaps we could bribe macallan :-)

> If the only reason we cannot switch to 3-level MMU pmap is HP-MMU,
> those machines (at least HP320) need more special work, including
> userland binaries, to keep them "supported".  That's my point.

Eh, I don’t see it as a huge burden.  I don’t see a real tangible benefit to switching the ‘851/‘030 over to a 3-level scheme just to match the 68040.  The pmap design I’m working with keeps the page tables in an rb-tree (and eliminates the fixed-size “user PT map” that linearly maps the user PTEs), and deals with “leaf” as part of the lookup key.  Whether that is a 2nd or 3rd level table is irrelevant unless the leaf table doesn’t exist at which point the code paths diverge to deal with page table allocation.  And it handles 8K and 4K pages the same (just sizes the objects in the pools the PTs are allocated from differently).

> I wonder if HP350 (that has RAMs on its local bus, not 16-bit DIO bus?)
> supports CAS/TAS instructions (i.e. read-modified-write cycle), but
> I have not have a chance to acquireq it.
> 
> Does anyone still have HP350 and tried recent NetBSD (5.0 and later)
> on it?
> 
> Thanks,
> ---
> Izumi Tsutsui

-- thorpej