admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Implement SCSI WRITE(10), closing the graph's highest-leverage blocker

Browse Source 
Direct mirror of the existing READ(10) implementation (FABRIC-3.md §F.1),
data direction flipped: new XHCI_XFER_BOT_DATA_OUT/XHCI_NEXT_ACTION_BOT_DATA_OUT
states, xhci_bot_send_write10()/xhci_bot_write_block()/xhci_bot_write_data_out()
in xhci.c, new SCSI_CMD_WRITE10 opcode and BOT_CMD_WRITE10/BOT_TUR_CHAIN_WRITE10
enum values. usb_blk_write() in blkio_usb.c is real now, no longer the
BLKIO_ENOSUP stub. read_only flips to 0 in blkio_info() now that it's proven.

Verified live end-to-end on all three architectures with a genuine cold-reboot
round-trip (not just a same-session read): BLK-CONFIRM-FORMAT's BAM/reloc
writes and an explicit block content write both completed via clean WRITE10
cycles (CSW PASS), and the written byte read back correctly after a full
kernel rebuild + fresh boot -- amd64=65, aarch64=170, riscv64=201, each at
LBN 32734 on a disposable usbwrite-test.img attached via QEMU usb-storage.

Added Makefile.starkernel's QEMU_EXTRA (empty by default, no behavior change)
to attach the disposable test image for this validation; the drive must be
hotplugged via QMP after boot reaches ok>, not attached at QEMU launch --
attaching before xhci_bringup()'s controller reset means no fresh Port
Status Change event fires (see project_xhci_milestone_2d_polling memory).

Found and reported, not fixed, during testing: EMPTY-BUFFERS
(empty_all_buffers(), block_words.c) does not implement standard Forth-79
semantics -- it force-writes zero to every block on every attached device
instead of discarding cache assignments. This corrupted disk/artemis.img
during an earlier test run; restored from git, confirmed byte-identical.
Avoided in the final validation runs (detach/reattach used instead to force
a fresh read).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZGkimpfyh63EZyRkNbkPD
This commit is contained in:
Robert Allan James
2026-08-28 07:19:31 -04:00
co-authored by Claude Sonnet 5
parent ff67bbdec3
commit 5e9802845a
15 changed files with 89095 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
include/starkernel/blkio_usb.h
+6 -4
View File
@@ -6,10 +6,12 @@
* driver's synchronous bridge (xhci_bot_wait_for_idle(), xhci_bot_get_capacity(),
* xhci_bot_read_block()) from Milestone 2h's foundational increment.
*
* Read-only this increment: no SCSI WRITE(10) exists in the xHCI driver yet
* (block_subsystem.c's own attach-time disk probing never writes, per
* blk_format_or_load_disk()'s "NEVER writes to disk here" discipline, so a
* read-only backend is sufficient to land this piece first).
* Read-write since 2026-08-28 (FABRIC-3.md §F.1): SCSI WRITE(10) is real
* (xhci_bot_send_write10()/xhci_bot_write_block()/xhci_bot_write_data_out(),
* xhci.c), mirroring READ(10)'s existing CBW/data-stage/CSW machinery with
* the data direction flipped. Verified live on amd64: BLK-CONFIRM-FORMAT's
* BAM/reloc zero-page writes and an explicit block content write both
* survived a cold reboot and read back correctly.
*
* Only one USB MSC device is supported (single-outstanding-transaction
* scope, matching the xHCI driver it sits on).
include/starkernel/xhci.h
+8
View File
@@ -306,6 +306,14 @@ typedef struct {
#define SCSI_CMD_READ10 0x28u
#define SCSI_CDB_LEN_READ10 10u
/* SCSI WRITE(10) (SBC-3 section 5.32) -- direct mirror of READ(10): same
* 10-byte CDB layout (opcode, LBA, transfer length), opposite data
* direction (host -> device). See xhci_bot_send_write10()'s own doc
* comment for the CBW-level difference (bmCBWFlags clears the DATA_IN
* bit instead of setting it). */
#define SCSI_CMD_WRITE10 0x2Au
#define SCSI_CDB_LEN_WRITE10 10u
/* SCSI TEST UNIT READY (SPC-4 section 6.33) -- 6-byte CDB, all-zero apart
* from the opcode, no data stage. Convention (not spec-mandated, but
* standard SCSI target behavior): the first command a target sees after
include/starkernel/xhci_driver.h
+89 -3
View File
@@ -116,6 +116,7 @@ typedef struct {
XHCI_XFER_SET_CONFIG,
XHCI_XFER_CBW_SENT,
XHCI_XFER_BOT_DATA_IN,
XHCI_XFER_BOT_DATA_OUT,
XHCI_XFER_CSW_RECEIVED
} transfer_purpose;
uint32_t pending_transfer_slot_id;
@@ -202,7 +203,8 @@ typedef struct {
BOT_CMD_NONE = 0,
BOT_CMD_TEST_UNIT_READY,
BOT_CMD_READ10,
BOT_CMD_READ_CAPACITY10
BOT_CMD_READ_CAPACITY10,
BOT_CMD_WRITE10
} bot_cmd_kind;
enum {
BOT_STATUS_IDLE = 0,
@@ -218,12 +220,19 @@ typedef struct {
enum {
BOT_TUR_CHAIN_NONE = 0,
BOT_TUR_CHAIN_READ10,
BOT_TUR_CHAIN_READ_CAPACITY10
BOT_TUR_CHAIN_READ_CAPACITY10,
BOT_TUR_CHAIN_WRITE10
} bot_tur_chain_target;
uint32_t bot_tur_retries;
uint32_t bot_read10_lba;
uint16_t bot_read10_num_blocks;
uint32_t bot_read10_block_size;
/* WRITE(10) mirror of bot_read10_* above -- kept as separate fields
* rather than renaming/reusing the read ones, so the already-tested
* READ10 path is never touched by this addition (FABRIC-3.md §F.1). */
uint32_t bot_write10_lba;
uint16_t bot_write10_num_blocks;
uint32_t bot_write10_block_size;
/* Latched from a successful READ CAPACITY(10) Data-In reply -- see
* SCSI_CMD_READ_CAPACITY10's own doc comment in xhci.h for field
* meaning. Untouched (stale) on a FAILED/TIMEOUT completion; callers
@@ -282,10 +291,12 @@ typedef struct {
XHCI_NEXT_ACTION_CONFIGURE_ENDPOINT,
XHCI_NEXT_ACTION_SET_CONFIG,
XHCI_NEXT_ACTION_BOT_DATA_IN,
XHCI_NEXT_ACTION_BOT_DATA_OUT,
XHCI_NEXT_ACTION_BOT_CSW_RECEIVE,
XHCI_NEXT_ACTION_BOT_SEND_TUR,
XHCI_NEXT_ACTION_BOT_SEND_READ10,
XHCI_NEXT_ACTION_BOT_SEND_READ_CAPACITY10
XHCI_NEXT_ACTION_BOT_SEND_READ_CAPACITY10,
XHCI_NEXT_ACTION_BOT_SEND_WRITE10
} next_action;
uint32_t next_action_slot_id;
uint16_t next_action_length;
@@ -501,6 +512,45 @@ int xhci_cmd_configure_endpoint(xhci_dev_t *dev, uint32_t slot_id);
int xhci_bot_send_read10(xhci_dev_t *dev, uint32_t slot_id, uint32_t lba,
uint16_t num_blocks, uint32_t block_size);
/*
* xhci_bot_send_write10 — build a Command Block Wrapper for a SCSI
* WRITE(10) and submit it on the bulk OUT
* Transfer Ring; the Data-Out stage and CSW
* receive follow automatically once this CBW's
* own completion arrives (see
* xhci_bot_write_data_out()/xhci_bot_receive_csw()
* below) -- direct mirror of
* xhci_bot_send_read10() above, same deferred-
* chaining pattern, opposite data direction.
*
* Unlike READ(10), the caller must have already placed the num_blocks*
* block_size bytes to be written into dev->bot_data_buf *before* calling
* this -- there is no separate "stage the payload" step, matching how
* xhci_bot_read_block()'s caller reads the result back out of
* bot_data_buf only *after* the whole chain completes. bmCBWFlags is 0
* (host -> device data stage), not USB_BOT_CBW_FLAG_DATA_IN -- the one
* CBW-level difference from xhci_bot_send_read10(). CDB layout (SBC-3
* section 5.32) is otherwise identical to READ(10)'s: opcode, then LBA
* and Transfer Length as the same big-endian fields.
*
* lba/num_blocks/block_size have the same meaning and the same
* num_blocks*block_size <= sizeof(dev->bot_data_buf) bound as
* xhci_bot_send_read10(). Requires the same bulk endpoint/ring
* prerequisites -- refuses if any are missing.
*
* Returns 0 if the CBW was posted, -1 if a prerequisite is missing or
* the requested transfer size exceeds dev->bot_data_buf.
*
* Low-level primitive -- sets dev->bot_cmd_kind = BOT_CMD_WRITE10 but
* does not run TEST UNIT READY first. Most callers want
* xhci_bot_write_block() below instead; this is called directly only by
* xhci_poll_events()'s own deferred dispatch
* (XHCI_NEXT_ACTION_BOT_SEND_WRITE10, once a prior TUR has reported
* PASS).
*/
int xhci_bot_send_write10(xhci_dev_t *dev, uint32_t slot_id, uint32_t lba,
uint16_t num_blocks, uint32_t block_size);
/*
* xhci_bot_send_test_unit_ready — build a Command Block Wrapper for SCSI
* TEST UNIT READY (6-byte CDB, no data
@@ -557,6 +607,27 @@ int xhci_bot_send_test_unit_ready(xhci_dev_t *dev, uint32_t slot_id);
int xhci_bot_read_block(xhci_dev_t *dev, uint32_t slot_id, uint32_t lba,
uint16_t num_blocks, uint32_t block_size);
/*
* xhci_bot_write_block — the real entry point for writing a block to the
* attached SCSI device. Direct mirror of
* xhci_bot_read_block() above: latches
* lba/num_blocks/block_size into
* dev->bot_write10_*, resets dev->bot_tur_retries
* to 0, and issues a TEST UNIT READY first rather
* than a bare WRITE(10), for the same first-command
* UNIT ATTENTION reason.
*
* As with xhci_bot_send_write10(), the caller must have already placed
* the payload bytes into dev->bot_data_buf before calling this.
*
* Returns 0 if TEST UNIT READY was posted, -1 if a prerequisite is
* missing or the requested transfer size exceeds dev->bot_data_buf (same
* check xhci_bot_send_write10() performs, done up front here so a bad
* request is rejected before spending a TUR round-trip on it).
*/
int xhci_bot_write_block(xhci_dev_t *dev, uint32_t slot_id, uint32_t lba,
uint16_t num_blocks, uint32_t block_size);
/*
* xhci_bot_send_read_capacity10 — build a Command Block Wrapper for SCSI
* READ CAPACITY(10) (SBC-3 section 5.14,
@@ -656,6 +727,21 @@ int xhci_bot_wait_for_idle(xhci_dev_t *dev, uint32_t max_iters);
*/
int xhci_bot_read_data_in(xhci_dev_t *dev, uint32_t slot_id);
/*
* xhci_bot_write_data_out — submit a Normal TRB on the bulk OUT Transfer
* Ring to write dev->bot_expected_data_len
* bytes from dev->bot_data_buf. Direct mirror
* of xhci_bot_read_data_in() above, opposite
* ring/direction.
*
* Called from xhci_poll_events()'s deferred next_action dispatch once a
* WRITE(10) CBW's own Command completion (XHCI_XFER_CBW_SENT) succeeds --
* not called directly by other code.
*
* Returns 0 if the TRB was posted, -1 if bulk_out_ring isn't set up.
*/
int xhci_bot_write_data_out(xhci_dev_t *dev, uint32_t slot_id);
/*
* xhci_bot_receive_csw — submit a Normal TRB on the bulk IN Transfer Ring
* to read the 13-byte Command Status Wrapper into