github-starred/RhapsodiOS

Watch

Fork 0

mirror of https://github.com/RhapsodiOS/RhapsodiOS.git synced 2026-11-03 22:01:40 -07:00

[GH-ISSUE #63] ppc: 0700_Devices probe failures on Sawtooth (serial interrupts, Floppy panic, missing built-in drivers) #56

New issue

Closed

opened 2026-11-03 22:03:24 -07:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-11-03 22:03:24 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/63

Booting our ppc kernel (branch ppc-qemu) with the Mac OS X Server 1.2v3 disk on QEMU mac99 (Sawtooth), /etc/startup/0700_Devices prints:

Using Default table for PPCAwacs
_IOProbeDriver: No Such Device, device PPCAwacs unit 0
Using Default table for drvPPCBurgundy
_IOProbeDriver: No Such Device, device drvPPCBurgundy unit 0
Using Default table for DEC21x4Ethernet
_IOProbeDriver: No Such Device, device DEC21x4Ethernet unit 0
...
Registering: PPCSerialPort0   [ch-a]
Registering: PPCSerialPort1   [ch-b]
ch-a: couldn't get interrupts.
ch-b: couldn't get interrupts.
...
_IOProbeDriver: No Such Device, device SCSITape unit 0
_IOProbeDriver: No Such Device, device PPCSerialPort unit 0
_IOProbeDriver: No Such Device, device SCSIServer unit 0

0700_Devices runs driverLoader D=<name> for a fixed list on every ppc machine, and _IOProbeDriver reports when nothing in the device tree matches the driver's Matching. So most of these are expected, but a few are real problems.

Expected on mac99 (no hardware)

PPCAwacs (awacs davbus) and drvPPCBurgundy (burgundy davbus): QEMU's mac99 has no sound node. A real Sawtooth has a davbus/Screamer, so check this on hardware or with a QEMU that models audio.
DEC21x4Ethernet: no tulip when the guest uses sungem. vm/ppc-guest.py loads it by name and adds pci1011,19 to its match.
SCSITape and SCSIServer: no SCSI controller.

Needs work

PPCSerialPort: ch-a/ch-b: couldn't get interrupts. IOTreeDevice -resolveInterrupts builds the escc channels' interrupt list, then setInterruptList: fails. On mac99 the ESCC sits under mac-io with two-cell MPIC specifiers. Check what the ch-a/ch-b nodes carry, and what our new mapInterrupts: path (b25b3c196) makes of them. The trailing "No Such Device, device PPCSerialPort" is the second driverLoader pass after PortServer.
Floppy: panics instead of probing. Loading it calls mpic_register_int(PMAC_DEV_FLOPPY), and 136 is not in sawtooth_interrupts, which panics with "Interrupt 136 not found". The stock 5.6 kernel does the same. A probe for absent hardware should fail cleanly; mpic_register_int should not panic for an unknown device. vm/ppc-guest.py currently drops the Floppy load from 0700_Devices.
Built-in drivers 5.6 has and we don't build. The 5.6 kernel's in-kernel config table includes UniNEnet (gmac, the Sawtooth's built-in Ethernet), DEC21x4 (apple21143 plus the 21x4x PCI IDs), AttoScsi and PowerSupply. src/kernel-7/bsd/dev/ppc/drvUniNEnet exists but is in neither conf/files.ppc nor autoconf_ppc.m, so on our kernel a Sawtooth's GMAC only works through a patched drvPPCGem loadable.

Related: #61, #62.

Originally created by @raynorpat on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/63 Booting our ppc kernel (branch `ppc-qemu`) with the Mac OS X Server 1.2v3 disk on QEMU `mac99` (Sawtooth), `/etc/startup/0700_Devices` prints: ``` Using Default table for PPCAwacs _IOProbeDriver: No Such Device, device PPCAwacs unit 0 Using Default table for drvPPCBurgundy _IOProbeDriver: No Such Device, device drvPPCBurgundy unit 0 Using Default table for DEC21x4Ethernet _IOProbeDriver: No Such Device, device DEC21x4Ethernet unit 0 ... Registering: PPCSerialPort0 [ch-a] Registering: PPCSerialPort1 [ch-b] ch-a: couldn't get interrupts. ch-b: couldn't get interrupts. ... _IOProbeDriver: No Such Device, device SCSITape unit 0 _IOProbeDriver: No Such Device, device PPCSerialPort unit 0 _IOProbeDriver: No Such Device, device SCSIServer unit 0 ``` `0700_Devices` runs `driverLoader D=<name>` for a fixed list on every ppc machine, and `_IOProbeDriver` reports when nothing in the device tree matches the driver's `Matching`. So most of these are expected, but a few are real problems. ## Expected on mac99 (no hardware) - **PPCAwacs** (`awacs davbus`) and **drvPPCBurgundy** (`burgundy davbus`): QEMU's mac99 has no sound node. A real Sawtooth has a `davbus`/Screamer, so check this on hardware or with a QEMU that models audio. - **DEC21x4Ethernet**: no tulip when the guest uses sungem. `vm/ppc-guest.py` loads it by name and adds `pci1011,19` to its match. - **SCSITape** and **SCSIServer**: no SCSI controller. ## Needs work 1. **PPCSerialPort: `ch-a`/`ch-b: couldn't get interrupts`.** `IOTreeDevice -resolveInterrupts` builds the escc channels' interrupt list, then `setInterruptList:` fails. On mac99 the ESCC sits under mac-io with two-cell MPIC specifiers. Check what the `ch-a`/`ch-b` nodes carry, and what our new `mapInterrupts:` path (b25b3c196) makes of them. The trailing "No Such Device, device PPCSerialPort" is the second `driverLoader` pass after `PortServer`. 2. **Floppy: panics instead of probing.** Loading it calls `mpic_register_int(PMAC_DEV_FLOPPY)`, and 136 is not in `sawtooth_interrupts`, which panics with "Interrupt 136 not found". The stock 5.6 kernel does the same. A probe for absent hardware should fail cleanly; `mpic_register_int` should not panic for an unknown device. `vm/ppc-guest.py` currently drops the Floppy load from `0700_Devices`. 3. **Built-in drivers 5.6 has and we don't build.** The 5.6 kernel's in-kernel config table includes `UniNEnet` (`gmac`, the Sawtooth's built-in Ethernet), `DEC21x4` (`apple21143` plus the 21x4x PCI IDs), `AttoScsi` and `PowerSupply`. `src/kernel-7/bsd/dev/ppc/drvUniNEnet` exists but is in neither `conf/files.ppc` nor `autoconf_ppc.m`, so on our kernel a Sawtooth's GMAC only works through a patched `drvPPCGem` loadable. Related: #61, #62.

gitea-mirror

2026-11-03 22:03:24 -07:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-11-03 22:03:26 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 18, 2026):

Item 3 (built-in drivers) on branch ppc-qemu:

UniNEnet is built in now (b6e11b19d): it's in conf/files.ppc and in the built-in table (gmac, priority 7200, as in 5.6). The reconstruction needed fixes before it worked:
- descriptor structs were BMac's 32/48-byte DBDMA layouts, so _initTxRing ran off its page
- the GEM ring-size field was programmed as log2(n) instead of log2(n/32) (4096 entries instead of 128)
- TX was kicked with 0 instead of the tail
- the RX status/flags were read from the wrong descriptor words, and the reset clobbered the buffer address
- the flag that gates _startChip was named chipIdVerified, so the MAC was never enabled
- a raw self + 0x5c4 write
- API slips (IOPMPowerState, relativeTimeout:, two-argument attachToNetworkWithAddress::, MII names)
It also keeps the RX MAC summary bit masked. That is a divergence from 5.6, which unmasks it, but nothing services it. On QEMU mac99, en0 now comes from UniNEnet ("Ethernet(UniN): Link is up at 100Mb - Full Duplex"), with no patched loadable.
AdaptecU2SCSI stays out of the build. Its source is far from compiling (duplicate methods, missing types and APIs, no HIM core), so it needs a reconstruction pass. Its built-in table entry now has 5.6's full match list.
AttoScsi (AttoScsiInit.m/AttoScsiMisc.m empty), PowerSupply (no source) and in-kernel DEC21x4 (only the loadable project) are unchanged.

sawtooth_interrupts now matches the 5.6 table source for source (c14acd573). That needed new device ids in drvPExpert's interrupts.h (PMAC_DMA_UIDE, PMAC_DEV_UIDE, USB0/1, CARD12-25), and PMAC_DEV_PDS, which is unused, moved to 282 so no value is duplicated.

@raynorpat commented on GitHub (Oct 18, 2026): Item 3 (built-in drivers) on branch `ppc-qemu`: - **UniNEnet is built in now** (b6e11b19d): it's in `conf/files.ppc` and in the built-in table (`gmac`, priority 7200, as in 5.6). The reconstruction needed fixes before it worked: - descriptor structs were BMac's 32/48-byte DBDMA layouts, so `_initTxRing` ran off its page - the GEM ring-size field was programmed as `log2(n)` instead of `log2(n/32)` (4096 entries instead of 128) - TX was kicked with 0 instead of the tail - the RX status/flags were read from the wrong descriptor words, and the reset clobbered the buffer address - the flag that gates `_startChip` was named `chipIdVerified`, so the MAC was never enabled - a raw `self + 0x5c4` write - API slips (`IOPMPowerState`, `relativeTimeout:`, two-argument `attachToNetworkWithAddress::`, MII names) It also keeps the RX MAC summary bit masked. That is a divergence from 5.6, which unmasks it, but nothing services it. On QEMU mac99, `en0` now comes from UniNEnet ("Ethernet(UniN): Link is up at 100Mb - Full Duplex"), with no patched loadable. - **AdaptecU2SCSI** stays out of the build. Its source is far from compiling (duplicate methods, missing types and APIs, no HIM core), so it needs a reconstruction pass. Its built-in table entry now has 5.6's full match list. - **AttoScsi** (`AttoScsiInit.m`/`AttoScsiMisc.m` empty), **PowerSupply** (no source) and in-kernel **DEC21x4** (only the loadable project) are unchanged. `sawtooth_interrupts` now matches the 5.6 table source for source (c14acd573). That needed new device ids in drvPExpert's `interrupts.h` (`PMAC_DMA_UIDE`, `PMAC_DEV_UIDE`, `USB0/1`, `CARD12-25`), and `PMAC_DEV_PDS`, which is unused, moved to 282 so no value is duplicated.

gitea-mirror commented

2026-11-03 22:03:27 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 18, 2026):

Status on branch ppc-qemu (local):

PPCSerialPort couldn't get interrupts: still open.
Floppy panic: fixed in 97dc15f7f. The kernel skips the Floppy probe when there is no swim3, and an interrupt missing from the table now warns instead of panicking.
Built-in drivers. These are now built in as 5.6 has them:
- UniNEnet (b6e11b19d)
- DEC21x4, reconstructed from 5.6 with its 5.6 matching (582f67fd1)
- PowerSupply, reconstructed with its hw.powersupply sysctl (62700b0a9)
Built-in Ethernet uses 5.6's load priority, 7200 (492a0d32b), and UniNEnet links after DEC21x4 as in 5.6 (016e76f77). The loadable DEC21x4Ethernet project's stub was replaced with the reconstructed driver (3b78bd622). AttoScsi (empty AttoScsiInit.m/AttoScsiMisc.m) and AdaptecU2SCSI (doesn't compile) are still out of the build.

I haven't booted the built-in DEC21x4 and PowerSupply in QEMU yet.

@raynorpat commented on GitHub (Oct 18, 2026): Status on branch `ppc-qemu` (local): 1. **PPCSerialPort `couldn't get interrupts`**: still open. 2. **Floppy panic**: fixed in 97dc15f7f. The kernel skips the Floppy probe when there is no swim3, and an interrupt missing from the table now warns instead of panicking. 3. **Built-in drivers**. These are now built in as 5.6 has them: - UniNEnet (b6e11b19d) - DEC21x4, reconstructed from 5.6 with its 5.6 matching (582f67fd1) - PowerSupply, reconstructed with its `hw.powersupply` sysctl (62700b0a9) Built-in Ethernet uses 5.6's load priority, 7200 (492a0d32b), and UniNEnet links after DEC21x4 as in 5.6 (016e76f77). The loadable `DEC21x4Ethernet` project's stub was replaced with the reconstructed driver (3b78bd622). AttoScsi (empty `AttoScsiInit.m`/`AttoScsiMisc.m`) and AdaptecU2SCSI (doesn't compile) are still out of the build. I haven't booted the built-in DEC21x4 and PowerSupply in QEMU yet.

gitea-mirror commented

2026-11-03 22:03:28 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 23, 2026):

Update on branch ppc-qemu (not pushed yet): every driver the 5.6 kernel has built in is now reconstructed and built into ours.

5.6 built-in	Status
UniNEnet	built in (`b6e11b19d`); drives QEMU mac99's sungem
DEC21x4	built in (`582f67fd1`); also matches `pci1011,19` (`79679149d`, a labelled divergence from 5.6), so it drives QEMU g3beige's tulip
PowerSupply	built in (`62700b0a9`)
AttoScsi	reconstructed and built in (merged in `f93514f04`)
AdaptecU2SCSI (Ultra2)	reconstructed and built in (`f7765cdb5`, merged in `dd8c20603`)

Item 2, the Floppy panic, was fixed in 97dc15f7f.

Still open: item 1. PPCSerialPort still logs ch-a/ch-b: couldn't get interrupts on mac99, and nothing on the branch has touched it. Leaving this issue open for that.

AttoScsi and AdaptecU2SCSI have no hardware under QEMU's ppc machines, so neither has been run under QEMU or on hardware yet.

@raynorpat commented on GitHub (Oct 23, 2026): Update on branch `ppc-qemu` (not pushed yet): every driver the 5.6 kernel has built in is now reconstructed and built into ours. | 5.6 built-in | Status | |---|---| | UniNEnet | built in (`b6e11b19d`); drives QEMU mac99's sungem | | DEC21x4 | built in (`582f67fd1`); also matches `pci1011,19` (`79679149d`, a labelled divergence from 5.6), so it drives QEMU g3beige's tulip | | PowerSupply | built in (`62700b0a9`) | | AttoScsi | reconstructed and built in (merged in `f93514f04`) | | AdaptecU2SCSI (Ultra2) | reconstructed and built in (`f7765cdb5`, merged in `dd8c20603`) | Item 2, the Floppy panic, was fixed in `97dc15f7f`. Still open: item 1. `PPCSerialPort` still logs `ch-a`/`ch-b: couldn't get interrupts` on mac99, and nothing on the branch has touched it. Leaving this issue open for that. AttoScsi and AdaptecU2SCSI have no hardware under QEMU's ppc machines, so neither has been run under QEMU or on hardware yet.

gitea-mirror commented

2026-11-03 22:03:28 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 23, 2026):

Item 1, the serial couldn't get interrupts lines, is fixed on ppc-qemu (not pushed yet), which closes this issue's last open item.

Cause. The serial ports were never broken; the message came from duplicate device-tree nodes. On mac99, OpenBIOS (like Apple's New World firmware) has both escc and escc-legacy under mac-io. Each has ch-a/ch-b children with identical interrupts: 0x25/0x04/0x05 for ch-a. PPCSerialPort matches ch-a ch-b, so the escc channels registered. Then the escc-legacy channels tried to allocate the same IRQ items in IOTreeDevice -resolveInterrupts and failed.

Fix. 2d710454f makes IODeviceTreeBus -probeBus skip escc-legacy, next to the existing AAPL,ignore skip. It's labelled as a divergence from 5.6.

Checked on QEMU mac99, with the guest's serial port on a TCP socket:

Both ports register: PPCSerialPort0 [ch-a] and PPCSerialPort1 [ch-b].
The couldn't get interrupts lines are gone.
/dev/cuaa passes data both ways: host to guest (PING-RX-12345, which needs the receive interrupt) and guest to host (TX-FROM-GUEST).

Two more fixes were needed to rebuild the kernel from the current branch. Both came in when master was merged into ppc-qemu:

65dd3fa09: restores keylargo_string_property_is, which the merge dropped. The kernel didn't link without it.
816e04420: the DAVbus probe hung Sawtooth boot. It walked mac-io's children with a heap-allocated DT iterator from configure_sawtooth, before kalloc_init, so kfree spun in lock_write. It now uses a new allocation-free DTIterateChildren. davbus_binding_test passes (122 checks, 0 failures) after adding a DTFindChildEntry mock; that mock had been missing since the earlier i2c lookup change.

The g3beige serial gap, where OpenBIOS lists one SCC interrupt instead of three, is tracked in #79.

@raynorpat commented on GitHub (Oct 23, 2026): Item 1, the serial `couldn't get interrupts` lines, is fixed on `ppc-qemu` (not pushed yet), which closes this issue's last open item. **Cause.** The serial ports were never broken; the message came from duplicate device-tree nodes. On mac99, OpenBIOS (like Apple's New World firmware) has both `escc` and `escc-legacy` under mac-io. Each has `ch-a`/`ch-b` children with identical interrupts: `0x25`/`0x04`/`0x05` for ch-a. `PPCSerialPort` matches `ch-a ch-b`, so the `escc` channels registered. Then the `escc-legacy` channels tried to allocate the same IRQ items in `IOTreeDevice -resolveInterrupts` and failed. **Fix.** `2d710454f` makes `IODeviceTreeBus -probeBus` skip `escc-legacy`, next to the existing `AAPL,ignore` skip. It's labelled as a divergence from 5.6. **Checked on QEMU mac99,** with the guest's serial port on a TCP socket: - Both ports register: `PPCSerialPort0 [ch-a]` and `PPCSerialPort1 [ch-b]`. - The `couldn't get interrupts` lines are gone. - `/dev/cuaa` passes data both ways: host to guest (`PING-RX-12345`, which needs the receive interrupt) and guest to host (`TX-FROM-GUEST`). **Two more fixes were needed to rebuild the kernel from the current branch.** Both came in when master was merged into ppc-qemu: - `65dd3fa09`: restores `keylargo_string_property_is`, which the merge dropped. The kernel didn't link without it. - `816e04420`: the DAVbus probe hung Sawtooth boot. It walked mac-io's children with a heap-allocated DT iterator from `configure_sawtooth`, before `kalloc_init`, so `kfree` spun in `lock_write`. It now uses a new allocation-free `DTIterateChildren`. `davbus_binding_test` passes (122 checks, 0 failures) after adding a `DTFindChildEntry` mock; that mock had been missing since the earlier i2c lookup change. The g3beige serial gap, where OpenBIOS lists one SCC interrupt instead of three, is tracked in #79.