MK4001MTD USB ब्रिज

RP2040 Pico फर्मवेयर जो Toshiba MK4001MTD 0.85" SDIO माइक्रोड्राइव को USB मास स्टोरेज डिवाइस के रूप में ब्रिज करता है।

MK4001MTD एक 4 GB माइक्रोड्राइव है जो मूल रूप से Nokia N91 म्यूज़िक फ़ोन और कुछ अन्य डिवाइसों, जैसे MP3 प्लेयर या USB ड्राइव, में उपयोग किया जाता था, जब फ्लैश स्टोरेज अभी भी काफी महंगा था।

आपने परिचय देखे होंगे जो दावा करते हैं कि यह ड्राइव MMC प्रोटोकॉल का उपयोग करता है, लेकिन यह वास्तव में गलत है। मैं कुछ समय से इसकी जांच कर रहा हूं: मैंने 8-बिट MMCplus कार्ड रीडर बनाने की कोशिश की और अलग-अलग SD/MMC रीडर का परीक्षण किया, लेकिन सफलता नहीं मिली। अंतिम उपाय के रूप में, मैंने एक Nokia N91 खरीदा ताकि लॉजिक ट्रेस कैप्चर कर सकूं और पुष्टि कर सकूं कि यह वास्तव में किस प्रोटोकॉल का उपयोग करता है।

यहाँ वह फोटो है जब मैं इसे अपने 8bit-MMCPlus रीडर बोर्ड के साथ उपयोग करने की कोशिश कर रहा था, और पता चला कि यह MMC नहीं है :(

इसलिए मैंने N91 लेकर ट्रेस इकट्ठा किए:

मानक ATA/CF माइक्रोड्राइव के विपरीत, यह CMD52/CMD53 के माध्यम से टनल किए गए ATA कमांड के साथ SDIO इंटरफ़ेस का उपयोग करता है। इस प्रोटोकॉल का समर्थन करने वाला कोई मौजूदा ड्राइवर नहीं है, इसलिए यह फर्मवेयर स्क्रैच से पूरा स्टैक लागू करता है।

यह मेरे लिए आश्चर्यजनक था, क्योंकि CE-ATA नामक एक SDIO-से-ATA मानक मौजूद है। लेकिन अगर आप रिलीज़ टाइमलाइन को ध्यान से देखें, तो CE-ATA इस ड्राइव के बाद आया। नतीजतन, यह ड्राइव पूरी तरह से SDIO कमांड पर निर्भर करता है, और CE-ATA उपलब्ध नहीं है। CE-ATA में दो नए कमांड CMD60/CMD61 हैं और यह CMD12/39 का उपयोग करता है, लेकिन आप ट्रेस से देख सकते हैं कि यह उनमें से किसी का भी उपयोग नहीं कर रहा है।

दूसरा हार्डवेयर बिंदु जिसका उल्लेख करना है, वह यह है कि एक और गलत जानकारी—जो यह दावा करती है कि यह 8-बिट MMCPlus कार्ड है—न केवल झूठी है, बल्कि पिनआउट MMC मानक का पालन नहीं करता है। आप Nokia N91 सर्विस मैनुअल पा सकते हैं जिसमें पिनआउट के बारे में कुछ दस्तावेज़ है: जबकि पिन नंबरिंग MMCPlus मानक का पालन करती है, पिन मैपिंग ऐसा नहीं करती। यह एक महत्वपूर्ण विवरण है यदि आप इसे स्वयं वायर कर रहे हैं: यह उसी MMC कनेक्टर का उपयोग करता है, लेकिन पिन मैपिंग अलग है, हार्डवेयर अनुभाग में और अधिक जानकारी।

अंत में, ध्यान दें कि इसे Claude/OpenClaw के साथ सह-विकसित किया गया है। मैंने मैन्युअल रूप से लॉजिक ट्रेस एकत्र किए और OpenClaw के लिए विकास पर पुनरावृत्ति करने के लिए एक क्लोज्ड-लूप टेस्ट स्टेशन स्थापित किया—ट्रेस का विश्लेषण करना और सुविधाओं को लागू करना। दस्तावेज़ीकरण मुख्य रूप से Claude द्वारा लिखा जाएगा; मैं इनलाइन अपने नोट्स भी जोड़ूंगा। मैंने दस्तावेज़ीकरण को स्वयं पढ़ा और दोबारा जांचा है, और यह विश्वसनीय और समझने में आसान होना चाहिए।

N91 ट्रेस पर विश्लेषण के बारे में अंतर्दृष्टि के लिए, यह /docs/N91_TRACE_ANALYSIS.md के अंतर्गत है, मैंने वहां N91 सर्विस मैनुअल के साथ रॉ लॉजिक ट्रेस भी डाल दिए हैं।

ब्लॉग पोस्ट में और देखें: https://www.willwhang.dev/Reading-MK4001MTD/
इसे क्रियाशील देखें: https://youtu.be/GC4xil3_Bbc

स्थिति

PIO-त्वरित रीड/राइट और आइडल पावर मैनेजमेंट के साथ पूरी तरह से कार्यात्मक USB मास स्टोरेज।

यह कैसे काम करता है

आर्किटेक्चर

USB Host ←→ USB MSC (TinyUSB) ←→ ATA Layer ←→ SDIO Layer (PIO) ←→ MK4001MTD

फर्मवेयर में चार परतें हैं:

1. USB MSC (msc_device.c) — TinyUSB मास स्टोरेज क्लास। SCSI READ(10)/WRITE(10) को ATA सेक्टर ऑपरेशन में अनुवादित करता है। 32 KB EP बफर, प्रति USB ट्रांसफर 64 सेक्टर तक बैचिंग। ड्राइव I/O दोनों दिशाओं में USB के साथ ओवरलैप किया जाता है, एक वास्तविक ATA-USB ब्रिज की तरह कैशिंग डिस्क के साथ: एक अनुक्रमिक-रीड प्रीफेचर अगले हिस्से को लाता है जबकि पिछला हिस्सा होस्ट को स्ट्रीम होता है, और राइट्स को स्टेज किया जाता है और फ्लश किया जाता है जबकि USB अगला टुकड़ा प्राप्त करता है। डिवाइस अपने राइट कैश का विज्ञापन करता है (कैशिंग मोड पेज, WCE=1 — होस्ट "राइट कैश: सक्षम" रिपोर्ट करते हैं और fsync/unmount/suspend पर SYNCHRONIZE CACHE जारी करते हैं, जिसे फर्मवेयर मानता है)। एक असफल बैकग्राउंड फ्लश अगले WRITE या SYNCHRONIZE CACHE पर MEDIUM ERROR के रूप में सामने आता है; ज्ञात-खराब सेक्टरों पर लिखना एक सख्त सिंक्रोनस पथ लेता है।

2. ATA-over-SDIO (ata_sdio.c) — SDIO फ़ंक्शन 1 एड्रेस स्पेस में CMD52 के माध्यम से मैप किए गए ATA रजिस्टरों में लिखकर और CMD53 के माध्यम से सेक्टर डेटा स्थानांतरित करके ATA कमांड (IDENTIFY, READ SECTORS, WRITE SECTORS) लागू करता है। CMD, डेटा और ATA स्तरों पर 3-स्तरीय रीट्री लॉजिक।

3. PIO SDIO (sdio_pio.c, sdio.pio) — RP2040 के PIO पेरीफेरल का उपयोग करके हार्डवेयर-त्वरित SDIO (4-बिट बस 10 MHz पर, इनपुट सिंक्रोनाइज़र को बायपास करके प्रति बिट 4 PIO चक्र)। तीन PIO प्रोग्राम डायनामिक प्रोग्राम स्वैपिंग के माध्यम से एकल स्टेट मशीन साझा करते हैं:

   • CMD tx/rx (24 निर्देश) — SDIO कमांड भेजता है और प्रतिक्रियाएँ प्राप्त करता है
   • DAT पढ़ें (12 निर्देश) — बाइट-स्वैपिंग DMA (कोई CPU रीपैक नहीं) के माध्यम से 4-बिट DAT बस से डेटा ब्लॉक पढ़ता है; ब्लॉक N का CRC सत्यापित होता है जबकि ब्लॉक N+1 स्ट्रीम होता है
   • DAT लिखें (14 निर्देश) — DMA के माध्यम से 4-बिट DAT बस पर डेटा ब्लॉक लिखता है, अंतर्निहित CRC स्थिति रिसेप्शन और बिजी-वेट के साथ; ब्लॉक N+1 की निबल स्ट्रीम बनती है जबकि ब्लॉक N स्थानांतरित होता है

4. पिन/पावर (sdio_hw.c) — GPIO आरंभीकरण और HDD पावर नियंत्रण। सभी SDIO संचार PIO का उपयोग करता है।

मानव नोट्स: दिलचस्प बात यह है कि Claude PIO में SDIO लागू करने के लिए वास्तव में अनिच्छुक था, और PIO और बिट-बैंगिंग के बीच आगे-पीछे जाने में बहुत सारे विकास चक्र बर्बाद हुए।

SDIO-ATA प्रोटोकॉल

MK4001MTD एक I/O फ़ंक्शन वाले SDIO कार्ड के रूप में प्रस्तुत होता है। मानक SDIO कार्ड आरंभीकरण (CMD5/CMD3/CMD7) बस सेट करता है, फिर ATA रजिस्टरों तक SDIO कमांड के माध्यम से पहुंचा जाता है:

रजिस्टर एक्सेस (CMD52): प्रत्येक ATA रजिस्टर फ़ंक्शन 1 एड्रेस पर मैप किया गया है:

डेटा स्थानांतरण (CMD53): सेक्टर डेटा को DATA रजिस्टर (पता 0x00) को लक्षित करते हुए ब्लॉक मोड में CMD53 जारी करके स्थानांतरित किया जाता है। मल्टी-सेक्टर रीड के लिए, block_count=N के साथ एक एकल CMD53 N × 512 बाइट्स को एक SDIO मल्टी-ब्लॉक लेनदेन में स्थानांतरित करता है।

इंटरप्ट सिग्नलिंग: ड्राइव SDIO इंटरप्ट (CCCR रजिस्टर 0x05 में INT_PENDING बिट 1) को सक्रिय करके सेक्टर तत्परता का संकेत देता है। ATA STATUS रजिस्टर पढ़ने से इंटरप्ट साफ हो जाता है।

पढ़ने का पथ (मल्टी-ब्लॉक PIO)

16-सेक्टर रीड के लिए:

1. PIO CMD52 के माध्यम से ATA रजिस्टर लिखें:
     SECCOUNT=16, LBA_LO/MID/HI, DEV/HEAD=0xE0, CMD=0x20

2. CMD52 के माध्यम से STATUS को पोल करें जब तक DRQ (बिट 3) सेट न हो

3. PIO को DAT पढ़ने के प्रोग्राम में बदलें
4. CMD53 भेजें: block_mode=1, fn=1, addr=0x0000, block_count=16

5. PIO DAT पढ़ें: 16 ब्लॉकों में से प्रत्येक के लिए:
   a. स्टार्ट बिट (सभी DAT लाइनें कम) की प्रतीक्षा करें
   b. PIO RX FIFO से बफर में 1024 निबल्स (512 बाइट्स) का DMA करें
   c. SM के CRC+एंड निबल्स को क्लॉक करने के लिए समाप्त होने की प्रतीक्षा करें (SM PC पोल करें)
   d. निबल्स → बाइट्स को इन-प्लेस में रीपैक करें

6. PIO को CMD प्रोग्राम में वापस बदलें

लिखने का पथ (मल्टी-ब्लॉक PIO)

16-सेक्टर राइट के लिए:

1. PIO CMD52 के माध्यम से ATA रजिस्टर लिखें:
     SECCOUNT=16, LBA, DEV/HEAD=0xE0, CMD=0x30

2. CMD52 के माध्यम से STATUS को पोल करें जब तक DRQ (बिट 3) सेट न हो
   (STATUS 0xD8 = BSY+DRQ को DRQ-तैयार माना जाता है, N91 ट्रेस के अनुसार)

3. PIO को DAT लिखने के प्रोग्राम में बदलें
4. CMD53 भेजें: block_mode=1, fn=1, addr=0x0000, block_count=16

5. PIO DAT लिखें: 16 ब्लॉकों में से प्रत्येक के लिए:
   a. प्रति DAT लाइन CRC16-CCITT की पूर्व-गणना करें (4 स्वतंत्र CRCs)
   b. निबल स्ट्रीम बनाएं: start(0x0) + data(1024 निबल्स) + CRC(16) + end(0xF)
   c. निबल स्ट्रीम को PIO TX FIFO में DMA करें
   d. PIO सभी निबल्स को क्लॉक करता है, फिर:
      - DAT को इनपुट पर स्विच करता है
      - कार्ड से CRC स्थिति के लिए 16 चक्र क्लॉक करता है
      - कार्ड द्वारा बिजी जारी होने तक DAT0 को पोल करता है
      - ब्लॉक पूर्णता का संकेत देने के लिए IRQ 0 फायर करता है

6. PIO को CMD प्रोग्राम में वापस बदलें

PIO प्रोग्राम स्वैपिंग

RP2040 PIO में प्रति ब्लॉक 32 इंस्ट्रक्शन स्लॉट हैं। हमारे तीन प्रोग्राम कुल 55 निर्देश हैं, इसलिए वे सह-अस्तित्व में नहीं रह सकते। इसके बजाय, PIO0 पर एक एकल SM0 का उपयोग किया जाता है, और प्रोग्राम को सीधे PIO इंस्ट्रक्शन मेमोरी में लिखकर स्वैप किया जाता है:

static void load_program_raw(const pio_program_t *program) {
    for (uint i = 0; i < program->length; i++)
        pio->instr_mem[FIXED_OFFSET + i] = program->instructions[i];
}

यह SDK के pio_add_program/pio_remove_program आवंटक को बायपास करता है। प्रोग्राम स्वैप में लगभग ~1 µs लगता है। प्रत्येक स्वैप के बाद एक प्रोग्राम-विशिष्ट पुनः आरंभ होता है जो पिन मैपिंग, शिफ्ट दिशा और क्लॉक डिवाइडर सेट करता है।

पावर प्रबंधन

Nokia N91 लॉजिक ट्रेस के विश्लेषण से आक्रामक पावर प्रबंधन का पता चलता है:

• आइडल मोड: STANDBY IMMEDIATE (0xE0) हर ~7.5 सेकंड में, बिना किसी I/O के भी। प्रत्येक स्टैंडबाय पूर्ण SDIO पुनः-आरंभीकरण (CMD5 रीट्री → CMD3 → CMD7 → CCCR सेटअप) को ट्रिगर करता है। एक आइडल सत्र में 28 स्टैंडबाय चक्र देखे गए।
• सक्रिय मोड: I/O के बर्स्ट के बीच स्टैंडबाय जारी किया गया (USB ड्राइव फ़ाइल ऑपरेशन के दौरान 24 चक्र)।
• कोई अन्य पावर कमांड (IDLE, SLEEP, CHECK POWER MODE) या CCCR पावर रजिस्टर एक्सेस नहीं देखा गया।

फर्मवेयर इस व्यवहार को एक कॉन्फ़िगरेबल आइडल टाइमआउट के साथ दोहराता है:

#define IDLE_STANDBY_MS 5000  // main.c में

दो पथ HDD पावर गेटिंग को ट्रिगर करते हैं:

1. आइडल टाइमआउट (5 सेकंड) — मुख्य लूप कोई I/O गतिविधि नहीं पाता है
2. USB सस्पेंड — होस्ट USB पोर्ट को सस्पेंड करता है

दोनों पथ राइट कैश को फ्लश करने और हेड पार्क करने के लिए ATA STANDBY IMMEDIATE (0xE0) भेजते हैं, फिर GP9 के माध्यम से पावर काट देते हैं।

जागृति अनुक्रम (गेट के बाद पहले READ/WRITE द्वारा ट्रिगर):

1. HDD चालू करें, रेल सेटल होने के लिए 500ms प्रतीक्षा करें
2. PIO-आधारित SDIO पुनः आरंभ: CMD5 (OCR) → 10ms सेटल → CMD3 (RCA) → CMD7 (चयन)
3. फास्ट PIO क्लॉक पर स्विच करें, CMD52 के माध्यम से CCCR कॉन्फ़िगर करें (4-बिट बस, 512B ब्लॉक, fn1 सक्षम)
4. fn1 तैयार पोल करें (CCCR IO_READY बिट 1)
5. N91-शैली 30ms DRDY स्थिति पोल जब तक ड्राइव ATA-तैयार न हो

खराब सेक्टर हैंडलिंग

जब एक मल्टी-सेक्टर स्थानांतरण एक खराब सेक्टर से टकराता है:

1. चंक पढ़ना विफल होता है → त्रुटि पुनर्प्राप्ति (IO_ABORT + fn1 रीसेट, ~500ms)
2. विफल होने वाले ब्लॉक को सटीक रूप से पहचानने के लिए प्रति-सेक्टर I/O पर वापस आता है
3. ATA परत विफलता को सामान्य DRQ timeout में समेटने के बजाय अंतिम STATUS/ERROR बिट्स को कैप्चर करने के लिए पर्याप्त प्रतीक्षा करती है
4. कोई भी अपुनर्प्राप्त ब्लॉक SCSI कमांड को तुरंत MEDIUM ERROR के साथ विफल करता है (पढ़ें: 03/11/00, लिखें: 03/0C/00)
5. खराब-सेक्टर LBA कैश किया गया → दोहराए गए रीड बिना ड्राइव को फिर से हथौड़े मारे तेजी से विफल होते हैं (होस्ट रीट्री स्टॉर्म के खिलाफ एंटी-हैमर सुरक्षा)
6. राइट हमेशा मीडिया को छूते हैं, प्रति SBC — कैश किए गए-खराब LBA पर एक सफल राइट इसे कैश से साफ कर देता है, ठीक उसी तरह जैसे कोई ड्राइव लंबित सेक्टर को साफ करता है

बिंदु 6 शैक्षणिक नहीं है: इस ड्राइव में LBA 1952 पर एक लंबे समय से अपठनीय सेक्टर था (READ: ST=0x51 ERR ERR=0x40 UNC)। एक बार जब ब्रिज ने एक राइट को वास्तव में उस तक पहुंचने दिया, तो ड्राइव ने सेक्टर को फिर से लिखा और यह तब से साफ पढ़ता है:

[ATA] FAST-RD: ST=0x51 ERR ERR=0x40 UNC LBA=1952
[MSC] BAD SECTOR read LBA=1952
[MSC] Bad sector LBA=1952 repaired by write

निर्माण

आवश्यक शर्तें

• Raspberry Pi Pico SDK — स्टॉक, अपरिवर्तित, 2.2.0 पर पिन किया गया
• ARM टूलचेन (arm-none-eabi-gcc)
• CMake

SDK संस्करण लॉक है: यदि PICO_SDK_PATH सेट है (पर्यावरण या CMake वेरिएबल), तो इसका उपयोग किया जाता है और इसके संस्करण की पिन के विरुद्ध जाँच की जाती है — एक बेमेल कॉन्फ़िगर को निर्देशों के साथ विफल कर देता है (ओवरराइड करें -DMK4001_ALLOW_SDK_MISMATCH=ON के साथ)। बिना किसी PICO_SDK_PATH के, पिन किए गए SDK रिलीज़ को कॉन्फ़िगर समय पर GitHub से स्वचालित रूप से लाया जाता है, इसलिए एक नंगे git clone && cmake && make पूरी तरह से प्रतिलिपि प्रस्तुत करने योग्य है।

फर्मवेयर को एक पैच किए गए TinyUSB MSC क्लास ड्राइवर की आवश्यकता है (रीड/राइट त्रुटियों पर संरक्षित ऐप सेंस डेटा + WCE=1 के साथ कैशिंग मोड पेज)। वह फ़ाइल इस रेपो में वेंडर की गई है lib/tinyusb_patched/msc_device.c पर — बिल्ड स्वचालित रूप से SDK की प्रतिलिपि के बजाय इसे संकलित करता है, इसलिए कभी भी SDK सर्जरी की आवश्यकता नहीं होती है। अपस्ट्रीम TinyUSB (0.18.0, के रूप में pico-sdk 2.2.0 के साथ बंडल) के विरुद्ध अंतर lib/tinyusb_patched/ में है; SDK पिन ठीक इसलिए मौजूद है क्योंकि इस वेंडर की गई फ़ाइल को SDK के TinyUSB को ट्रैक करना चाहिए।

निर्माण और फ्लैश

cd /home/pi/mk4001_bridge/build
cmake ..
make -j4

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
  -c "adapter speed 1000" -c "init" -c "reset halt" -c "sleep 200" \
  -c "program /home/pi/mk4001_bridge/build/mk4001_bridge.elf verify" \
  -c "reset run" -c "exit"

हार्डवेयर वायरिंग

नोट: GP0 और GP1 इस विशिष्ट Pico यूनिट पर मृत हैं। सभी SDIO पिन असाइनमेंट +2 स्थानांतरित हैं।

मानव नोट्स: Claude यहाँ गलत था क्योंकि उसने महसूस नहीं किया कि GP0 और GP1 का उपयोग इसके बिल्ड कॉन्फ़िगरेशन में UART टर्मिनल के लिए किया जा रहा था। यह इसे भूलता रहा, इस हद तक कि मैंने बस SDIO GPIO को उस UART से हटा दिया।

HDD_PWR आवश्यक नहीं है। ड्राइव का उपयोग करने के लिए आपको इसे पावर-साइकिल करने की आवश्यकता नहीं है; जब बहुत सी चीजें हार्ड-कोडेड होती हैं तो यह HDD को रीसेट करने के लिए एक विकास सुविधा है। यही कहा जाए, यदि आप बिजली की बचत चाहते हैं, तो आप उस सिग्नल का उपयोग कर सकते हैं, लेकिन यह बिना किसी समस्या के वार्म रीसेट को संभाल सकता है।

आप UART पर डीबग संदेश देखेंगे। वे USB-CDC के माध्यम से नहीं जा रहे हैं क्योंकि Claude के लिए एक अलग UART-से-USB लॉगिंग लिंक स्थापित करना आसान था जो प्रारंभिक विकास के दौरान डिस्कनेक्ट या अस्थिर नहीं होता है।

UART लॉग ड्राइव के सक्रिय होने पर हर 30 सेकंड में ड्राइव तापमान भी रिपोर्ट करता है ([TEMP] drive temperature: 29 C)। सेंसर Toshiba वेंडर कमांड 0xC2 को रिवर्स-इंजीनियर करके खोजा गया था — N91 इसे अपने HDD ऑपरेटिंग-तापमान सीमाओं को लागू करने के लिए प्रत्येक ड्राइव सत्र की शुरुआत में पढ़ता है। विवरण docs/N91_TRACE_ANALYSIS.md §4 में।

यहाँ लॉग का एक उदाहरण है:

========================================
  MK4001MTD USB Bridge v0.11
  SDIO-ATA → USB Mass Storage (PIO)
========================================

[MAIN] Pre-delay 5000ms...
[PIO] Init OK: clkdiv=3.12 (~10.0 MHz), CMD@0
[MAIN] Power cycling HDD...
[SDIO] HDD power OFF
[SDIO] HDD power ON
[MAIN] SDIO init (PIO)...
[SDIO] CMD5 ready (OCR=0x901F8000)
[SDIO] RCA=0x0001
[SDIO] fn1 ready (attempt 0)
[MAIN] ATA IDENTIFY...
[ATA] IDENTIFY complete
Model:    [TOSHIBA MK4001MTD]
Serial:   [           763B004HA]
Firmware: [VH173A]
Sectors:  7862400 (3839 MB)
SMART:    not supported (supported=0, enabled=0)
IDENTIFY: W0=0040 W47=0000 W49=0000 W59=0000
  ATA W80=0000  Cmd W82=0000 W83=0000 W84=0000
  En  W85=0000 W86=0000 W87=0000  W89=0008 W128=0001

[DIAG] === Drive Diagnostics ===
[DIAG] Standard SMART: not supported (IDENTIFY W82 bit0 = 0)
[DIAG] Toshiba vendor CMD 0xC2:
  FEAT=0x01 unknown_01                       → SC=00 LBA=02/00/00 ST=50
  FEAT=0x02 unknown_02                       â SC=00 LBA=02/00/00 ST=50
  FEAT=0x03 unknown_03                       → SC=00 LBA=02/00/00 ST=50
  FEAT=0x04 unknown_04                       → SC=00 LBA=02/00/00 ST=50
  FEAT=0x10 diag_10 (LBA_LO varies)          → SC=00 LBA=00/00/00 ST=50
  FEAT=0x11 diag_11                          → SC=00 LBA=00/00/00 ST=50
  FEAT=0x12 diag_12 (LBA_LO varies)          → SC=00 LBA=01/00/00 ST=50
  FEAT=0x20 query_20 (N91: SC=0xFF always)   → SC=FE LBA=00/FF/00 ST=50
  FEAT=0x21 query_21 (N91: SC varies per boot) → SC=1B LBA=00/FF/00 ST=50

[MAIN] MBR: valid 0x55AA
[MAIN] Warming up...
[MAIN] PIO OK, STATUS=0x50
[MAIN] Drive: 7862400 sectors (3839 MB)
[MAIN] Ready.
[PWR] Idle 5000ms → STANDBY + power gate
[PWR] STANDBY IMMEDIATE → power gate
[SDIO] HDD power OFF

अंत में, यहाँ वास्तविक ड्राइव के लिए वायरिंग है।
यहाँ N91 स्कीमैटिक से एक क्रॉप है, आप पिन नंबर भी मैप कर सकते हैं।

साइड नोट कि यह 3V ड्राइव है लेकिन मुझे लगता है कि 3.3V ठीक है, ज्यादातर यह कुछ लेवल शिफ्टिंग काम को बचाने के लिए है।

विशेष रूप से इस ड्राइव के लिए डिज़ाइन किया गया HW /hardware के अंतर्गत है!

स्रोत फ़ाइलें

संस्करण इतिहास

परीक्षण

# Check device appeared
lsblk -dno NAME,MODEL | grep MK4001

# Filesystem test — mount, copy files, verify
sudo mount /dev/sdX1 /mnt/mk4001
cp /tmp/testfile /mnt/mk4001/
sync
md5sum /tmp/testfile /mnt/mk4001/testfile    # should match
sudo umount /mnt/mk4001

# Speed benchmarks (raw device, do NOT mount first — will corrupt filesystem)
# Use a safe offset past the filesystem or an unpartitioned drive
sudo dd if=/dev/sdX of=/dev/null bs=64k count=128 iflag=direct     # read
sudo dd if=/dev/zero of=/dev/sdX bs=64k count=64 oflag=direct seek=1024  # write (offset past FS)

यहाँ मानव नोट्स, मजेदार तथ्य: जब यह पहली बार गति परीक्षण करना शुरू करता है, तो यह वास्तव में सीधे ड्राइव पर dd करता है और फाइलसिस्टम को नुकसान पहुंचाता है..... शुक्र है कि विकास के दौरान इससे ज्यादा फर्क नहीं पड़ता, लेकिन हमेशा ध्यान रखें जब आप अपना सेटअप OpenClaw को संभालें।

लाइसेंस

मुझे परवाह नहीं है।