Add data response token validation in SD/MMC write operations

[Copilot]

The drive_write_block() function was not validating the data response token that SD/MMC cards send after receiving data in SPI mode. Per SD specification section 7.3.3.1, this token indicates whether data was accepted or rejected due to CRC/write errors. Without validation, write failures go undetected, causing silent data corruption.

Changes

• Added constants for response token validation:

  • DATA_RESPONSE_MASK (0x1F): Extracts bits [4:0] from response byte
  • DATA_RESPONSE_ACCEPTED (0x05): Expected value for successful writes (format: xxx00101)

• Modified drive_write_block() to read and validate the response token immediately after CRC16 transmission, before waiting for card busy state:

// write dummy crc16
spi_send_byte(0xff);
spi_send_byte(0xff);

// read and verify data response token
uint8_t response = spi_rec_byte();
if ((response & DATA_RESPONSE_MASK) != DATA_RESPONSE_ACCEPTED) {
  tfs_last_error = TFS_ERR_IO;
  return;
}

// wait while card is busy (card pulls line low during programming)
if (!wait_byte(0xff)) {
  tfs_last_error = TFS_ERR_IO;
  return;
}

The token format is xxx0sss1 where bits [3:1] encode status: 010 = accepted, 101 = CRC error, 110 = write error.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• esm.ubuntu.com
  • Triggering command: /usr/lib/apt/methods/https /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Issue: Missing Data Response Token Validation in SD/MMC Write Operations

Problem Description

The drive_write_block() function in mmc.c does not verify the data response token that the SD/MMC card sends after receiving data. According to the SD/MMC specification, after sending a data block, the card responds with a data response token that indicates whether the data was accepted, rejected due to CRC error, or rejected due to write error.

Current code (lines 332-340):

// write dummy crc16
spi_send_byte(0xff);
spi_send_byte(0xff);

// wait while card is busy
if (!wait_byte(0xff)) {
    tfs_last_error = TFS_ERR_IO;
    return;
}

Impact

HIGH PRIORITY - Without checking the data response token:

• Write errors (CRC errors, write protect violations, etc.) go completely undetected
• Data corruption may occur silently without any error indication
• The filesystem may believe data was written successfully when it actually failed
• Could lead to filesystem corruption in production systems

SD/MMC Specification

According to the SD/MMC specification for SPI mode, the data response token format is:

xxx0sss1

Where sss indicates:

• 010 (0x05 when masked) = Data accepted
• 101 (0x0B when masked) = Data rejected due to CRC error
• 110 (0x0D when masked) = Data rejected due to write error

The response must be checked before waiting for the card to finish its busy state.

Correct Implementation

The proper sequence should be:

// write dummy crc16
spi_send_byte(0xff);
spi_send_byte(0xff);

// read and verify data response token
uint8_t response = spi_rec_byte();
if ((response & 0x1F) != 0x05) {  // Check if data accepted (xxx00101)
    tfs_last_error = TFS_ERR_IO;
    return;
}

// wait while card is busy (card pulls line low during programming)
if (!wait_byte(0xff)) {
    tfs_last_error = TFS_ERR_IO;
    return;
}

Requirements

1. ✅ Add data response token reading after CRC transmission
2. ✅ Verify the response token indicates "data accepted" (bits [3:1] = 010)
3. ✅ Return error if response indicates CRC error or write error
4. ✅ Maintain existing timeout and busy-wait behavior
5. ✅ Add comments explaining the response token format
6. ✅ (Optional) Define constants for response token values for better code clarity:

   #define DATA_RESPONSE_MASK     0x1F
   #define DATA_RESPONSE_ACCEPTED 0x05

Testing Considerations

• Verify write operations still succeed on working cards
• Confirm that write errors are now properly detected and reported
• Ensure the change doesn't break compatibility with different card types (MMC, SD v1, SD v2, SDHC)
• Test with write-protected cards to verify proper error detection

References

• SD Specifications Part 1 Physical Layer Simplified Specification
• Section 7.3.3.1: Data Response Token
• The response is sent after data block and CRC reception

---

Priority: HIGH - This is a data integrity issue that could lead to silent data corruption.

This pull request was created from Copilot chat.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.