Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
Izumi Tsutsui <[email protected]> Sun, 7 Jan 2024 13:07:48 +0900
| Newsgroups | gmane.os.netbsd.ports.hp300,gmane.os.netbsd.ports.m68k |
|---|---|
| Message-ID | <[email protected]> |
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" The reason why is it looks memory bus design of these hardware don't support CAS instruction. 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: --- SELF-TEST MODE Copyright 1987, Hewlett-Packard Company. All Rights Reserved. BOOTROM Rev. C Bit Mapped Display MC68020 Processor MC68881 Coprocessor Keyboard RESET To Power-Up LOADING MEMORY SELF-TEST MODE HP-IB DMA-C0 TESTING MEMORY SELF-TEST MODE RAM 8388384 Bytes HP98644 (RS232) at 9 HP98625 (HPIB) at 14 HP98643 (LAN) at 21, 080009026A99 SEARCHING FOR A SYSTEM (RETURN To Pause) :HP7958, 1400, 0, 0 1Z SYS_UBOOT BOOTING A SYSTEM >> NetBSD/hp300 Primary Boot, Revision 1.21 (Thu Aug 4 15:30:37 UTC 2022) (from NetBSD 9.3) >> HP 9000/318/319/330 SPU >> Enter "reset" to reset system. Boot: [[[rd8a:]netbsd][-a][-c][-d][-s][-v][-q]] :- -s 3103228+137028 [371392+243934]=0x3ad8b8 Start @ 0xff803400 [1=0xffb19140-0x3ad8b8]... Entry point: 0xff803400 [ 1.0000000] bootinfo found at 0xff802000 [ 1.0000000] trap type 0, code = 0x1c5, v = 0x311a7c [ 1.0000000] kernel program counter = 0x1e0c0 [ 1.0000000] kernel: Bus error trap [ 1.0000000] pid = 0, lid = 1, pc = 0001E0C0, ps = 2710, sfc = 1, dfc = 1 [ 1.0000000] Registers: [ 1.0000000] 0 1 2 3 4 5 6 7 [ 1.0000000] dreg: 00000000 002EFB40 00000002 013E3000 0001E0B4 0001E0CE 00000000 0000001C [ 1.0000000] areg: 00311A7C 013E3000 00311A08 002F2148 00311A7C 0015E06C 003AFDE4 FFEFFFFC [ 1.0000000] Kernel stack (003AFBC0): [ 1.0000000] 3AFBC0: 00013620 003AFD18 00000080 00000002 013E3000 0001E0B4 0001E0CE 00000000 [ 1.0000000] 3AFBE0: 0000001C 00311A08 002F2148 00311A7C 0015E06C 003128D4 00312BE4 0030C73C [ 1.0000000] 3AFC00: 0001E0CE 00312C40 00000004 00000001 00000000 001A3F02 003133E8 00312BF0 [ 1.0000000] 3AFC20: 0001E0B4 003AFC5C 001A4094 003128D4 00312BE4 0030C73C 00000000 00000000 [ 1.0000000] 3AFC40: 001A3F02 0018271A 001700B0 001512D8 00312BE4 00312BF0 00312CD0 00001000 [ 1.0000000] 3AFC60: 00000000 00000000 00001000 00312BE4 003133E0 00312BF0 00000000 003AFC94 [ 1.0000000] 3AFC80: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.0000000] 3AFCA0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.0000000] 3AFCC0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.0000000] 3AFCE0: 00000000 00000000 00000000 00000000 00000000 00000000 013D16E0 013D1860 [ 1.0000000] 3AFD00: 003AFDE4 00001968 003AFD18 00000000 000001C5 00311A7C 00000000 002EFB40 [ 1.0000000] 3AFD20: 00000002 013E3000 0001E0B4 0001E0CE 00000000 0000001C 00311A7C 013E3000 [ 1.0000000] 3AFD40: 00311A08 002F2148 00311A7C 0015E06C 003AFDE4 FFEFFFFC 00000000 27100001 [ 1.0000000] 3AFD60: E0C0B008 1E2C01C5 66024E75 00311A7C 00311A7C 002EFB40 0ED00040 0001E0C8 [ 1.0000000] 3AFD80: 0001E0C6 0001E0C4 FFFAFFFF 00400040 000F11AF 00000000 00000002 00000040 [ 1.0000000] 3AFDA0: 00000040 C0200000 003AFDBC 0000D7EF 00000000 003AFDE8 0019CBEC 00311A7C [ 1.0000000] panic: Bus error [ 1.0000000] cpu0: Begin traceback... [ 1.0000000] ?(?) [ 1.0000000] db_panic(2714,0,ffffff7f,19fd40,3afbc0) at 0 [ 1.0000000] vpanic(25cf6a,3afbcc,3afd00,1363c,25cf6a) + 162 [ 1.0000000] panic(25cf6a,2,13e3000,1e0b4,1e0ce) + c [ 1.0000000] trap(3afd18,0,1c5,311a7c) + 268 [ 1.0000000] mutex_enter(?) [ 1.0000000] pool_get(311a08,2,2,13d69a4,13d692c) + c [ 1.0000000] pool_grow(13d692c,2) + 26a [ 1.0000000] pool_get(13d692c,2,13d6a1c,2710,0) + dc [ 1.0000000] pool_cache_get_slow(13d6aac,2710,3afe9c,0,2) + e6 [ 1.0000000] pool_cache_get_paddr(13d692c,2,0) + 90 [ 1.0000000] kmem_intr_alloc(?) [ 1.0000000] kmem_alloc(400,2) + 88 [ 1.0000000] hashinit(100,0,0,30c1cc,c) + a2 [ 1.0000000] uao_create(0,ff800000,2,13d1000,ff800000,3aff4c,3aff50,30c380,0,9c) + ee [ 1.0000000] uvm_init(c,ffffffff,ffffffff,3ae000,a1000002) + 9a [ 1.0000000] uvm_fault(0x30cb00, 0xa0fff000, 0x1) -> 0xe [ 1.0000000] type 8, code [mmu,,ssw]: 4810145 [ 1.0000000] trap type 8, code = 0x4810145, v = 0xa0fffffc [ 1.0000000] kernel program counter = 0x14304 [ 1.0000000] kernel: MMU fault trap [ 1.0000000] trap during panic! [ 1.0000000] pid = 0, lid = 1, pc = 00014304, ps = 2704, sfc = 1, dfc = 1 [ 1.0000000] Registers: [ 1.0000000] 0 1 2 3 4 5 6 7 [ 1.0000000] dreg: 00000004 00000004 003AFA8C 00000004 4AB90000 0000FFF2 00000001 0025A1A8 [ 1.0000000] areg: 003AFA8C A0FFFFFC A1000002 000AEB58 003AFB18 000B2EE0 003AFA6C FFEFFFFC [ 1.0000000] Kernel stack (003AF874): [ 1.0000000] 3AF874: 00013620 003AF9CC 00000080 003AFA8C 00000004 4AB90000 0000FFF2 00000001 [ 1.0000000] 3AF894: 0025A1A8 A1000002 000AEB58 003AFB18 000B2EE0 0030E6C8 0019FAAA 00000001 [ 1.0000000] 3AF8B4: 0030CB00 A0FFF000 00000000 003AF9E0 00000000 003AF9A0 003AF9A0 0026DB58 [ 1.0000000] 3AF8D4: 00000000 00000007 003128D4 00000000 003AF91F 00000006 00000000 00000000 [ 1.0000000] 3AF8F4: 00000000 0000000F 00000000 003AF9E0 00000001 0001E0B4 003AF944 003AF940 [ 1.0000000] 3AF914: 0003925E 002F5F14 003AF94C 0003925E 002F5F14 005BB010 00000000 0000000A [ 1.0000000] 3AF934: 0000000A 00000001 00000000 00000000 00000000 00000000 00000001 00000000 [ 1.0000000] 3AF954: 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000 [ 1.0000000] 3AF974: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.0000000] 3AF994: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 003AF9EB [ 1.0000000] 3AF9B4: 003AFA6C 00001968 003AF9CC 00000008 04810145 A0FFFFFC 00000004 00000004 [ 1.0000000] 3AF9D4: 003AFA8C 00000004 4AB90000 0000FFF2 00000001 0025A1A8 003AFA8C A0FFFFFC [ 1.0000000] 3AF9F4: A1000002 000AEB58 003AFB18 000B2EE0 003AFA6C FFEFFFFC 00000000 27040001 [ 1.0000000] 3AFA14: 4304B008 1C2C0145 60227202 A0FFFFFC 003AFA8C 00000004 20912091 0001430A [ 1.0000000] 3AFA34: 00014308 00014306 FFFFFFFF 6022FF04 000F1481 00000000 00000000 00003800 [ 1.0000000] 3AFA54: 00000000 80200000 003AFA7C 00000000 00A10000 003AFAA0 003AFA90 000AEB7A [ 1.0000000] Skipping crash dump on recursive panic [ 1.0000000] panic: MMU fault [ 1.0000000] Faulted in mid-traceback; aborting... Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x6: unlk a6 db> --- 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) 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 (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) 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. 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