Daniel Samson
3fb9d5936a
Flesh out the xHCI host-controller driver into a full transfer engine and build the three USB class drivers on top, all verified end to end under QEMU. - xHCI engine (usb-xhci-library.zig): controller reset, command/event rings with cycle-bit bookkeeping (gated on a No-Op-command proof), device slots, Address Device, control transfers, full chapter-9 enumeration, Configure Endpoint, and interrupt/bulk transfers. Each interface is device_registered with its (class,subclass,protocol) identity, unique per (port,interface). - Bus<->class transfer protocol (usb-transfer-protocol.zig + runtime.usb): open / control / interrupt-subscribe (async report pump on a poll timer) / bulk-by- physical-address, so sector data never crosses the 256-byte IPC limit. - USB HID keyboard + mouse (usb-hid/): decode boot-protocol reports and publish to the input service. A USB usage is already the input protocol's keycode. - USB mass storage (usb-storage/): Bulk-Only Transport + transparent SCSI, serving a block device under the new .block service id (block-protocol). - device-manager matches USB interfaces to class drivers (usbDriverForIdentity). - usb-abi / usb-ids made importable modules; add HID and mass-storage class requests, packTriple, and a usb_device DeviceClass. - Fix test/qemu_test.py on macOS: the QMP unix-socket path was built from the deep worktree path and exceeded the 104-byte sun_path limit, so QEMU exited before booting. It now lives under a short temp path. Tests: usb-report, usb-hid, usb-storage pass under python3 test/qemu_test.py; host units (usb-abi, usb-ids, hid-report, bulk-only-transport, scsi) green.
41 lines
1.6 KiB
Zig
41 lines
1.6 KiB
Zig
//! The block-device wire protocol — what a filesystem (the FAT server) says to a
|
|
//! block driver (usb-storage) over its well-known `.block` endpoint. A protocol
|
|
//! module like vfs-protocol / usb-transfer-protocol: extern-struct messages, an
|
|
//! `Operation` tag, everything in one IPC message.
|
|
//!
|
|
//! Data path: read and write move whole blocks to or from a **caller-owned DMA
|
|
//! buffer**, named by its physical address — the same physical-address handoff
|
|
//! usb-storage already uses toward the controller, one layer up. So a 512-byte
|
|
//! sector never has to cross the 256-byte IPC boundary; only the small request /
|
|
//! reply headers do. (Safe while the IOMMU is unenforced; see docs/driver-model.md.)
|
|
|
|
pub const Operation = enum(u32) {
|
|
/// geometry() -> { block_size, block_count }
|
|
geometry = 0,
|
|
/// read(lba, count, physical): read `count` blocks from `lba` into the buffer
|
|
read = 1,
|
|
/// write(lba, count, physical): write `count` blocks at `lba` from the buffer
|
|
write = 2,
|
|
};
|
|
|
|
pub const Request = extern struct {
|
|
operation: u32,
|
|
reserved: u32 = 0,
|
|
lba: u64,
|
|
count: u32, // number of blocks (read/write)
|
|
reserved2: u32 = 0,
|
|
physical: u64, // caller's DMA buffer physical address (read/write)
|
|
};
|
|
|
|
pub const Reply = extern struct {
|
|
status: i32, // 0 on success, negative on failure
|
|
reserved: u32 = 0,
|
|
block_size: u32, // geometry: bytes per block (512)
|
|
reserved2: u32 = 0,
|
|
block_count: u64, // geometry: total blocks; read/write: blocks moved
|
|
};
|
|
|
|
pub const message_maximum: usize = 256;
|
|
pub const request_size: usize = @sizeOf(Request);
|
|
pub const reply_size: usize = @sizeOf(Reply);
|