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

I have a couple 319C and 340 as well, not much RAM in them but I'm happy =
to run boot tests etc. if anyone needs them. (I'm also pretty physically =
near Jason if he wants to borrow one or more! I have a couple of =
9000-380, too, and 332=E2=80=A6)

  -- Chris

> On Jan 8, 2024, at 12:39=E2=80=AFAM, Anders Gustafsson =
<[email protected]> wrote:
>=20
> Hi!
>=20
> I have solicited input from the good folks at the vintage HP Groups. I =
myself have a 9000/340 and on that
> NetBSD runs, but slowly. Perhaps a bit too slow to be useful.
>=20
> --=20
> Med v=C3=A4nlig h=C3=A4lsning
>=20
> Anders Gustafsson, ingenj=C3=B6r
> [email protected]  |  Support +358 18 12060  |  Direkt +358 =
9 315 45 121  |  Mobil +358 40506 7099
>=20
> Pedago interaktiv ab, Nygatan 7 B , AX-22100 MARIEHAMN, =C3=85LAND, =
FINLAND
>=20
>=20
>=20
>>>> Jason Thorpe <[email protected]> 2024-01-07 07:25 >>>
>=20
>=20
>> On Jan 6, 2024, at 8:07=E2=80=AFPM, Izumi Tsutsui =
<[email protected]> wrote:
>>=20
>> thorpej@ wrote on port-m68k:
>> https://mail-index.netbsd.org/port-m68k/2024/01/06/msg000845.html=20
>>=20
>>>> 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=20=

>>>>=20
>>>> Maybe we also have to consider about 3-level pmap like sun3x..
>>>> https://mail-index.netbsd.org/port-m68k/2001/07/20/0003.html
>>>=20
>>> That's an idea, but that won't work for the HP MMU on the 320 / 350.
>>=20
>> 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"
>=20
> 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.
>=20
>> The reason why is it looks memory bus design of these hardware
>> don't support CAS instruction.
>=20
> 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 =E2=80=9Clock=E2=80=9D signal, I think.
>=20
>> 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:
>=20
> [ ROOTROM Rev. C boot message elided=E2=80=A6 ]
>=20
>> NetBSD/hp300 5.0 also fails in mutex_enter(9).
>> NetBSD/hp300 4.0.1 boots:
>> https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D6786=20
>>=20
>> (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.
>>=20
>> 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)
>=20
> Yah, it=E2=80=99s 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?
>=20
>> 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
>=20
> I think we should do some indirection there to support those models =
using RAS.  Perhaps I=E2=80=99m just nostalgic
> (or a luddite :-), but I think so long as the burden isn=E2=80=99t too =
great, we should try to keep these machines
> running.
>=20
>> (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)
>=20
> Perhaps we could bribe macallan :-)
>=20
>> 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.
>=20
> Eh, I don=E2=80=99t see it as a huge burden.  I don=E2=80=99t see a =
real tangible benefit to switching the =E2=80=98851/=E2=80=98030 over to
> a 3-level scheme just to match the 68040.  The pmap design I=E2=80=99m =
working with keeps the page tables in an
> rb-tree (and eliminates the fixed-size =E2=80=9Cuser PT map=E2=80=9D =
that linearly maps the user PTEs), and deals with =E2=80=9Cleaf=E2=80=9D
> as part of the lookup key.  Whether that is a 2nd or 3rd level table =
is irrelevant unless the leaf table
> doesn=E2=80=99t 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).
>=20
>> 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.
>>=20
>> Does anyone still have HP350 and tried recent NetBSD (5.0 and later)
>> on it?
>>=20
>> Thanks,
>> ---
>> Izumi Tsutsui
>=20
> -- thorpej
>=20