Port-m68k archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
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
Home |
Main Index |
Thread Index |
Old Index