Files
LithosAnanake/logs
Robert Allan JamesandClaude Sonnet 5 a88c004ecb Artemis Milestone 2g: CBW construction and send for SCSI READ(10)
First real use of the bulk Transfer Rings Configure Endpoint wired up.
xhci_bot_send_read10() builds a 31-byte Command Block Wrapper (USB Mass
Storage Class Bulk-Only Transport spec section 5.1) and submits it as a
single Normal TRB on the bulk OUT ring via a new
xhci_bulk_out_enqueue_and_ring() helper -- a CBW is always exactly one
TRB, so unlike the EP0 helper this one rings its own doorbell rather
than leaving that to a caller assembling a group.

usb_bot_cbw_t is a real struct (every field up to the CDB array is
naturally aligned, and this driver's targets are all little-endian
already assumed everywhere else), but its DMA length is the explicit
USB_BOT_CBW_LENGTH (31) constant, never sizeof(*cbw), since the
compiler may pad the struct to 32 bytes. The SCSI READ(10) CDB itself
is written byte-by-byte since its LBA/Transfer Length fields are
big-endian on the wire, unlike everything else in this driver -- the
one place two byte orders are both live in the same function.

Completion is correlated via the existing pending_transfer_slot_id/
transfer_purpose gate (new XHCI_XFER_CBW_SENT purpose) -- no
ring-specific dispatch needed, since this driver's single-outstanding-
transfer scope already implies which ring produced an event.

This covers construction and send only (one third of a full READ(10):
CBW -> Data-In stage -> CSW) -- reading the Data-In stage and CSW
receive/validation are separate, explicitly not-yet-implemented items.

Verified live via a temporary probe (written, run once, log captured,
reverted per this project's own probe convention) -- all three
architectures, byte-identical: CBW submitted -> CBW send completed,
then a clean disconnect even with the Data-In stage never drained
(confirms no wedge on a dangling BOT transaction). Probe-free
re-verification afterward on all three architectures.

FABRIC-2.md Section X Milestone 2g's CBW checklist item marked done.
Also records a monitoring gotcha hit three times this session: `ls -t`
over the logs/ tree can return a stale leftover log from an earlier
run in the same session -- fixed going forward by reading the log path
off the actual running QEMU process's own command line instead, and a
memory note added so it doesn't recur next session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R4VMX6VSKCten8nGgaMkq4
2026-08-25 09:07:33 -04:00
..
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00

logs/

QEMU acceptance-run history and Tripod smoke-test results.

  • <timestamp>/{amd64,aarch64,riscv64}/ — 255 timestamped three-arch QEMU acceptance run directories, one per invocation of the kernel QEMU acceptance workflow.
  • qemu-screenshot-*.png, qemu-screenshot-*.log, qemu-{amd64,aarch64,riscv64}-*.log, fbtest-console-*.png — loose timestamped QEMU serial captures and framebuffer screenshots from individual manual runs (not part of the timestamped-directory convention above).
  • hermes-tripod-smoke-results.md, hermes-channel-smoke-results.md — captured output from tools/hermes_tripod_smoke.sh and tools/hermes_channel_smoke.sh.
  • hermes-tripod-integration-design.md — design notes for the Tripod integration test.

Note: QEMU_BASELINE.log at the repo root (not in this directory) is the primary kernel regression baseline referenced by .claude/CLAUDE.md; the logs here are supplementary historical captures. See also logs2/ (a separate, flatter QEMU log archive) and experiments/bare_metal/runs/ (DoE-specific run output).