جسر MK4001MTD USB

برنامج ثابت لـ RP2040 Pico يوصل محرك Toshiba MK4001MTD 0.85" SDIO كجهاز تخزين كتلي USB.

محرك MK4001MTD هو محرك صغير سعة 4 جيجابايت كان يُستخدم أصلاً في هاتف Nokia N91 الموسيقي وبعض الأجهزة الأخرى، مثل مشغلات MP3 أو محركات USB، في وقت كانت فيه ذاكرة الفلاش لا تزال باهظة الثمن.

ربما تكون قد رأيت مقدمات تدّعي أن هذا المحرك يستخدم بروتوكول MMC، لكن هذا غير صحيح في الواقع. لقد كنت أبحث في هذا الأمر لبعض الوقت: حاولت بناء قارئ بطاقة MMCplus ذات 8 بت واختبرت عدة قُرّاء SD/MMC دون جدوى. كملاذ أخير، اشتريت هاتف Nokia N91 لالتقاط تتبعات منطقية وتأكيد البروتوكول الذي يستخدمه فعلياً.

هذه صورة عندما كنت أحاول استخدامه مع لوحة القارئ 8bit-MMCPlus الخاصة بي، واتضح أنه ليس MMC :(

لذا انتهى بي الأمر بشراء N91 لجمع التتبعات:

على عكس محركات ATA/CF الصغيرة القياسية، فهو يستخدم واجهة SDIO مع أوامر ATA مُمررة عبر CMD52/CMD53. لا يوجد مشغل موجود يدعم هذا البروتوكول، لذلك هذا البرنامج الثابت ينفذ المجموعة الكاملة من الصفر.

هذا الأمر فاجأني، لأن هناك معيار SDIO-to-ATA يسمى CE-ATA. لكن إذا نظرت عن كثب إلى الجدول الزمني للإصدارات، فإن CE-ATA جاء بعد هذا المحرك. ونتيجة لذلك، يعتمد هذا المحرك كلياً على أوامر SDIO، و CE-ATA غير متوفرة. CE-ATA لديها أمران جديدان CMD60/CMD61 وتستخدم CMD12/39، لكن يمكنك رؤية من التتبعات أنها لا تستخدم أيًا منها.

النقطة الثانية المتعلقة بالأجهزة هي أن معلومة خاطئة أخرى منتشرة – تدّعي أنها بطاقة MMCPlus ذات 8 بت – ليست غير صحيحة فحسب، بل إن ترتيب الأطراف لا يتبع معيار 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

الحالة

تخزين كتلي USB يعمل بكامل وظائفه مع قراءة/كتابة مُسرّعة عبر PIO وإدارة استهلاك الطاقة في وضع الخمول.

كيف يعمل

البنية

مضيف USB ←→ USB MSC (TinyUSB) ←→ طبقة ATA ←→ طبقة SDIO (PIO) ←→ MK4001MTD

يتكون البرنامج الثابت من أربع طبقات:

1. USB MSC (msc_device.c) — فئة التخزين الكتلي TinyUSB. يترجم أوامر SCSI READ(10)/WRITE(10) إلى عمليات قطاع ATA. مخزن مؤقت لنقطة النهاية 32 كيلوبايت، تجميع يصل إلى 64 قطاعًا لكل نقل USB. يتم تداخل إدخال/إخراج المحرك مع USB في كلا الاتجاهين، مثل جسر ATA-USB حقيقي مع قرص تخزين مؤقت: جالب مسبق للقراءة المتسلسلة يجلب الجزء التالي بينما يتم دفق الجزء السابق إلى المضيف، ويتم تخزين الكتابات مؤقتًا وتفريغها أثناء استقبال USB للجزء التالي. يعلن الجهاز عن ذاكرة التخزين المؤقت للكتابة (صفحة وضع التخزين المؤقت، WCE=1 — تقارير المضيفين "ذاكرة تخزين مؤقت للكتابة: ممكّنة" ويصدرون SYNCHRONIZE CACHE عند fsync/فك التركيب/التعليق، وهو ما يلتزم به البرنامج الثابت). يؤدي فشل التفريغ الخلفي إلى ظهور MEDIUM ERROR في عملية WRITE أو SYNCHRONIZE CACHE التالية؛ تأخذ الكتابات إلى القطاعات المعروفة بأنها تالفة مسارًا تزامنيًا صارمًا.

2. ATA-over-SDIO (ata_sdio.c) — ينفذ أوامر ATA (IDENTIFY، READ SECTORS، WRITE SECTORS) عن طريق الكتابة إلى سجلات ATA المُخطط لها في مساحة عنوان وظيفة SDIO 1 عبر CMD52، ونقل بيانات القطاع عبر CMD53. منطق إعادة محاولة من 3 مستويات على مستويات CMD والبيانات وATA.

3. PIO SDIO (sdio_pio.c, sdio.pio) — SDIO مُسرّع بالأجهزة باستخدام الطرفية PIO لـ RP2040 (ناقل 4 بت بسرعة 10 ميجاهرتز، 4 دورات PIO لكل بت مع تخطي مزامنات الإدخال). ثلاثة برامج PIO تشترك في آلة حالة واحدة عبر التبديل الديناميكي للبرنامج:

   • CMD إرسال/استقبال (24 تعليمة) — يرسل أوامر SDIO ويستقبل الردود
   • DAT قراءة (12 تعليمة) — يقرأ كتل البيانات من ناقل DAT ذو 4 بت عبر DMA تبادل البايت (بدون إعادة تجميع CPU)؛ يتم التحقق من CRC للكتلة N أثناء تدفق الكتلة N+1
   • DAT كتابة (14 تعليمة) — يكتب كتل البيانات إلى ناقل DAT ذو 4 بت عبر DMA، مع استقبال حالة CRC المدمج والانتظار حتى الانشغال؛ يتم بناء تيار nibble للكتلة N+1 أثناء نقل الكتلة N

4. الطرفية/الطاقة (sdio_hw.c) — تهيئة GPIO والتحكم في طاقة القرص الصلب. جميع اتصالات SDIO تستخدم PIO.

ملاحظات بشرية: من المثير للاهتمام، أن Claude كان مترددًا حقًا في تنفيذ SDIO في PIO، وتم إهدار الكثير من دورات التطوير في التبديل ذهابًا وإيابًا بين PIO والتلاعب بالبتات.

بروتوكول SDIO-ATA

يقدم MK4001MTD نفسه كبطاقة SDIO مع وظيفة إدخال/إخراج واحدة. تهيئة بطاقة SDIO القياسية (CMD5/CMD3/CMD7) تقوم بإعداد الناقل، ثم يتم الوصول إلى سجلات ATA من خلال أوامر SDIO:

الوصول إلى السجل (CMD52): يتم تعيين كل سجل ATA إلى عنوان وظيفة 1:

نقل البيانات (CMD53): يتم نقل بيانات القطاع عن طريق إصدار CMD53 في وضع الكتلة مستهدفًا سجل DATA (العنوان 0x00). للقراءات متعددة القطاعات، يقوم CMD53 واحد مع block_count=N بنقل N × 512 بايت في معاملة واحدة متعددة الكتل SDIO.

إشارات المقاطعة: يشير المحرك إلى جاهزية القطاع عن طريق تأكيد مقاطعة SDIO (بت INT_PENDING 1 في سجل CCCR 0x05). قراءة سجل STATUS ATA تمسح المقاطعة.

مسار القراءة (PIO متعدد الكتل)

لقراءة 16 قطاعًا:

1. كتابة سجلات ATA عبر PIO CMD52:
     SECCOUNT=16, LBA_LO/MID/HI, DEV/HEAD=0xE0, CMD=0x20

2. استقصاء STATUS عبر CMD52 حتى يتم تعيين DRQ (بت 3)

3. تبديل PIO إلى برنامج قراءة DAT
4. إرسال CMD53: block_mode=1, fn=1, addr=0x0000, block_count=16

5. PIO قراءة DAT: لكل من الكتل الـ 16:
   أ. انتظار بت البداية (جميع خطوط DAT منخفضة)
   ب. DMA 1024 nibble (512 بايت) من PIO RX FIFO إلى المخزن المؤقت
   ج. انتظار انتهاء SM من ساعة nibbles CRC+النهاية (استقصاء SM PC)
   د. إعادة تجميع nibbles → بايتات في المكان

6. تبديل PIO مرة أخرى إلى برنامج CMD

مسار الكتابة (PIO متعدد الكتل)

لكتابة 16 قطاعًا:

1. كتابة سجلات ATA عبر PIO CMD52:
     SECCOUNT=16, LBA, DEV/HEAD=0xE0, CMD=0x30

2. استقصاء STATUS عبر CMD52 حتى يتم تعيين 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:
   أ. حساب مسبق CRC16-CCITT لكل خط DAT (4 CRC مستقلة)
   ب. بناء تيار nibble: start(0x0) + data(1024 nibble) + CRC(16) + end(0xF)
   ج. DMA تيار nibble إلى PIO TX FIFO
   د. PIO يخرج جميع nibbles، ثم:
      - يبدل DAT إلى الإدخال
      - يولد 16 دورة لحالة CRC من البطاقة
      - يستقصي DAT0 حتى تطلق البطاقة الانشغال
      - يطلق IRQ 0 للإشارة إلى اكتمال الكتلة

6. تبديل PIO مرة أخرى إلى برنامج CMD

تبديل برنامج PIO

لدى RP2040 PIO 32 فتحة تعليمات لكل كتلة. برامجنا الثلاثة تحتوي على 55 تعليمة إجمالاً، لذا لا يمكنها التواجد معًا. بدلاً من ذلك، يتم استخدام SM0 واحد على PIO0، ويتم تبديل البرامج عن طريق الكتابة مباشرة إلى ذاكرة تعليمات 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 ثوانٍ، حتى بدون إدخال/إخراج. كل حالة استعداد تؤدي إلى إعادة تهيئة كاملة لـ SDIO (CMD5 retry → CMD3 → CMD7 → إعداد CCCR). لوحظ 28 دورة استعداد في جلسة خمول واحدة.
• الوضع النشط: يتم إصدار STANDBY بين دفعات الإدخال/الإخراج (24 دورة أثناء عمليات ملفات محرك USB).
• لم تُلاحظ أوامر طاقة أخرى (IDLE، SLEEP، CHECK POWER MODE) أو الوصول إلى سجل طاقة CCCR.

يكرر البرنامج الثابت هذا السلوك مع مهلة خمول قابلة للتكوين:

#define IDLE_STANDBY_MS 5000  // في main.c

مساران يؤديان إلى قطع طاقة القرص الصلب:

1. مهلة الخمول (5 ثوانٍ) — الحلقة الرئيسية تكتشف عدم وجود نشاط إدخال/إخراج
2. تعليق USB — المضيف يعلق منفذ USB

كلا المسارين يرسلان ATA STANDBY IMMEDIATE (0xE0) لتفريغ ذاكرة التخزين المؤقت للكتابة وإيقاف الرؤوس، ثم قطع الطاقة عبر GP9.

تسلسل الإيقاظ (يتم تشغيله بواسطة أول READ/WRITE بعد القطع):

1. تشغيل القرص الصلب، انتظر 500 مللي ثانية لاستقرار الجهد
2. إعادة تهيئة SDIO المستندة إلى PIO: CMD5 (OCR) → 10 مللي ثانية استقرار → CMD3 (RCA) → CMD7 (تحديد)
3. التبديل إلى ساعة PIO سريعة، تكوين CCCR عبر CMD52 (ناقل 4 بت، كتل 512 بايت، تمكين fn1)
4. استقصاء جاهزية fn1 (بت CCCR IO_READY 1)
5. استقصاء حالة DRDY على غرار N91 لمدة 30 مللي ثانية حتى يصبح المحرك جاهزًا ATA

التعامل مع القطاعات التالفة

عندما يواجه نقل متعدد القطاعات قطاعًا تالفًا:

1. فشل قراءة الدفعة → استعادة الخطأ (IO_ABORT + إعادة تعيين fn1، ~500 مللي ثانية)
2. التراجع إلى إدخال/إخراج لكل قطاع لتحديد الكتلة الفاشلة بدقة
3. تنتظر طبقة ATA لفترة كافية لالتقاط بتات STATUS/ERROR النهائية بدلاً من تحويل الفشل إلى "مهلة DRQ" عامة
4. أي كتلة غير مستردة تفشل أمر SCSI فورًا مع MEDIUM ERROR (قراءة: 03/11/00، كتابة: 03/0C/00)
5. يتم تخزين LBA القطاع التالف مؤقتًا → فشل قراءات التكرار بسرعة دون إعادة ضرب المحرك (حماية ضد عواصف إعادة المحاولة من المضيف)
6. الكتابات تلمس الوسيط دائمًا، وفقًا لـ SBC — كتابة ناجحة إلى LBA تالف مخبأ تمسحه من ذاكرة التخزين المؤقت، تمامًا مثلما يمسح المحرك قطاعًا معلقًا

النقطة 6 ليست أكاديمية: كان لهذا المحرك قطاع غير قابل للقراءة طويل الأمد عند LBA 1952 (قراءة: 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

البناء

المتطلبات الأساسية

• SDK Raspberry Pi Pico — أصلي، غير معدّل، مثبت على الإصدار 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 موجود تحديدًا لأن هذا الملف المضمن يجب أن يتتبع TinyUSB الخاص بـ SDK.

البناء والوميض

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 في تكوين البناء الخاص به. استمر في نسيان هذا، لدرجة أنني قمت ببساطة بنقل GPIOs SDIO بعيدًا عن UART تلك.

HDD_PWR ليس ضروريًا. ليس عليك إعادة تشغيل الطاقة للمحرك لاستخدامه؛ إنها بالأحرى وسيلة راحة تطويرية لإعادة تعيين القرص الصلب عندما تكون الكثير من الأشياء مشفرة بشكل ثابت. ومع ذلك، إذا كنت تريد توفير الطاقة، يمكنك استخدام تلك الإشارة، لكنها تستطيع التعامل مع إعادة التعيين الدافئ دون أي مشكلة.

سترى رسائل التصحيح عبر UART. إنها لا تمر عبر USB-CDC لأنه كان من الأسهل لـ Claude إعداد رابط تسجيل UART-to-USB منفصل لا ينقطع أو يصبح غير مستقر أثناء التطوير المبكر.

يسجل سجل UART أيضًا درجة حرارة المحرك كل 30 ثانية أثناء نشاط المحرك ([TEMP] drive temperature: 29 C). تم اكتشاف المستشعر عن طريق الهندسة العكسية لأمر البائع Toshiba 0xC2 — يقرأه N91 في بداية كل جلسة محرك لفرض حدود درجة حرارة تشغيل القرص الصلب الخاصة به. التفاصيل في 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، يمكنك تعيين رقم الطرف أيضًا.

ملاحظة جانبية: هذا محرك 3 فولت لكن أعتقد أن 3.3 فولت جيدة، بشكل أساسي لتوفير بعض أعمال تغيير مستوى الجهد.

تم تصميم الأجهزة خصيصًا لهذا المحرك تحت /hardware!

ملفات المصدر

سجل الإصدارات

الاختبار

# التحقق من ظهور الجهاز
lsblk -dno NAME,MODEL | grep MK4001

# اختبار نظام الملفات — تركيب، نسخ ملفات، تحقق
sudo mount /dev/sdX1 /mnt/mk4001
cp /tmp/testfile /mnt/mk4001/
sync
md5sum /tmp/testfile /mnt/mk4001/testfile    # يجب أن تتطابق
sudo umount /mnt/mk4001

# معايير السرعة (جهاز خام، لا تقم بالتركيب أولاً — سيتلف نظام الملفات)
# استخدم إزاحة آمنة بعد نظام الملفات أو محرك غير مقسم
sudo dd if=/dev/sdX of=/dev/null bs=64k count=128 iflag=direct     # قراءة
sudo dd if=/dev/zero of=/dev/sdX bs=64k count=64 oflag=direct seek=1024  # كتابة (إزاحة بعد نظام الملفات)

ملاحظات بشرية هنا، حقيقة مضحكة: عندما بدأ اختبار السرعة لأول مرة، قام بالفعل بعمل dd مباشرة على المحرك وأتلف أنظمة الملفات..... لحسن الحظ، لا يهم كثيرًا هنا أثناء التطوير، لكن ضع في اعتبارك دائمًا عند التعامل مع OpenClaw إعدادك.

الترخيص

لا يهمني.