| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Second OptiPlex QR: the Host System Error is gone (the 64-bit QH/qTD layout
fix worked), but the SETUP qTD now halts with TBYTES=0, C_ERR=3 and no
XactErr/Babble/DBE -- a split transaction with no valid response. PORTSC
shows CCS=1, PP=1 but PED=0, i.e. the port never enabled, so the split has no
TT to address. On Intel PCH a healthy USB2 port shows the rate-matching hub
as high-speed (PED=1), so the next step is to see every port's state.
- settle 100 ms after powering ports and clear stale change bits before the
reset walk (RMHs come up slower than direct devices)
- retry the port reset once after settling
- log a clear line when a connected port remains disabled
- retry a failed full-speed device as low-speed (the PORTSC speed field is
only valid once the port is enabled)
- persistent bottom-row summary: controller count, caps64, USB legacy handoff
result, every connected port's PORTSC and the HID device count. A hardware
run without serial now reports the whole picture instead of one QR.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First OptiPlex run: the controller halted with HSE (USBSTS bit4) 20 ms into
the first control transfer, with otherwise valid QH/qTD fields (control QH,
DTC, MPS 8, split hub 0/port 1, active qTD).
The PCH EHCI advertises HCCPARAMS bit0 (64-bit addressing capability), which
extends every QH with bufptr_hi[5] (17 dwords / 68 B) and every qTD the same
way (13 dwords / 52 B). Packing them 32-bit-style (48/32 B) made the
controller read the next qTD as the overlay's high buffer pointer and DMA to
a bogus 64-bit address -> Host System Error.
Space every structure for the 64-bit variant (32-bit controllers ignore the
tail): HID qTD at QH+0x80; control qTDs at QH+0x100/0x140/0x180 with the
setup packet at +0x1C0. The failure QR now reports the capability and the
DMA bases so the next hardware iteration is self-describing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hardening
EHCI (OptiPlex 7010 / Q77 and similar Intel PCH):
- enumerate *both* EHCI controllers (00:1a.0 + 00:1d.0), not just the first
- hub support: read the hub class descriptor, power/reset each port via hub
class requests, read the child speed, then drive the child with split
transactions carrying the hub's address and port (TT). On 7-series PCH the
root port presents the integrated Rate Matching Hub (8087:0024, class 9)
and the mouse/keyboard sit behind it; without this the driver stopped at
"no HID mouse/keyboard endpoint in config".
- HID mouse *and* keyboard, boot protocol + idle, per-device periodic QH
chained into the frame list, per-device report buffers and counters
- periodic re-arm follows the standard shape (qTD re-activated, Next-qTD
re-linked); the HC owns the status/toggle overlay
- DMA from the page allocator inside [16 MiB, 4 GiB): EHCI programs 32-bit
addresses and the page bitmap spans all RAM
- 2 ms recovery after SET_ADDRESS
xHCI:
- scratchpad buffers (HCSPARAMS2) and MaxSlotsEn > 1, with per-slot EP0 and
interrupt rings plus per-slot device contexts
- DMA from the page allocator instead of the heap allocator
- boot protocol + idle, mouse + keyboard, first-report diagnostics
- transfer events are routed to every device before matching a waiter, so a
second device's enumeration cannot swallow an armed device's report
shared:
- rsnix/src/hid.rs: HID usage -> scancode-set-1 tables, one scancode FIFO
feeding ps2::feed_scancode, per-device boot-keyboard report differ
- WM input pump polls PS/2 -> UHCI -> EHCI -> xHCI
- memory::alloc_pages_range(count, min, max) for bounded DMA allocations
QEMU coverage: make test-usb (EHCI + xHCI, mouse + keyboard). QEMU's EHCI
split path delivers only the first report for FS devices, so repeated-report
delivery and the RMH path remain hardware-test items.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- ehci: DEBUG_MATRIX was left true in be868a4, so every boot replaced
enumeration with the one-shot diagnostic transfer matrix and returned
false -- the EHCI driver never brought a device up. Default it off;
flip it back on only when bisecting a controller fault.
- new rsnix/src/hid.rs: boot-keyboard HID usage -> scancode-set-1
tables, the shared scancode FIFO, and a per-device report differ.
UHCI now uses it instead of its own copy, so EHCI/xHCI keyboards can
feed the same PS/2 decoder (`ps2::feed_scancode`).
- uhci: SET_PROTOCOL now asks for the boot protocol (wValue 0) instead
of report protocol (wValue 1). In report protocol the report layout
is device-defined, but every driver parses boot reports.
|
|
|
- Add polled EHCI (USB2) and UHCI (USB1.1) host-controller drivers with
HID boot mouse support, wired into cursor polling and the 'usb' shell cmd
- Add USB Legacy ownership handoff (claim_usb_legacy) plus config_write_byte
- Harden boot: verify the PIT/timer ticks before shell entry, EOI stray
interrupts in the LAPIC to stop interrupt storms, bound PS/2 controller
waits, and INTx-disable AHCI (polled driver)
- Add boot stage markers, klog screen echo, and QR lock; scheduler
mark_shell_running; NO_USB stopgap to keep BIOS USB-Legacy input alive
- alloc_pages_above for DMA buffers that must avoid low conventional memory
- Expand DEBUG_NOTES with EHCI/QEMU bring-up findings
|
