لدي شكوك في أن محاكي Texas Instruments JTAG لمعالجي تصحيح الأخطاء هو جهاز واسع الانتشار لدرجة أنه سيكون من المثير للاهتمام أن يقوم شخص ما بإنعاشه. ومع ذلك ، قد تكون المقالة مفيدة لأولئك الذين يحاولون إعادة تنشيط شيء ما بناءً على نظام Linux أحادي البطاقة ، بموارد ومعلومات محدودة. يمكنك اعتبار هذا بعض الأعمال العملية مع U-Boot.
بدلا من المقدمة
يعرف أي شخص يقوم بتصحيح البرامج الخاصة بالأنظمة المضمنة أنك بحاجة إلى استخدام أجهزة خاصة للاتصال بالمعالجات. تُستخدم محولات تسمى محاكيات JTAG لعائلة معالج Texas Instruments.
هناك العديد من الشركات المصنعة المختلفة. في متنزه بلدي ، من بين أمور أخرى ، يظهر Blackhawk USB560v2 . يجب أن أعترف ، ليس أرخص قطعة من الحديد. ثم توقفت في يوم من الأيام عن العمل دون سبب واضح.
الأعراض
حدث كل شيء يومًا ما ، توقف الجهاز عن التحميل واكتشف عبر USB. يومض مؤشر LED ، ولكنه لم يدخل في حالة "جاهز للاستخدام".
يحتوي هذا الجهاز على وضع موثق ترفيهي: بعد 10-15 تنزيلات غير ناجحة ، كان يجب أن يتحول إلى وضع خاص (الوضع الآمن) يسمح بإعادة تحميله. ومع ذلك ، رفض جهازي التبديل إلى هذا الوضع ، ولم يصل إلى مرحلة ترقيم USB ، وبالتالي لم يكن هناك أي إمكانية لإعادة تحميل الملف باستخدام الأداة المساعدة القياسية. لم تؤد المراسلات مع خدمة الدعم إلى أي شيء: رفضوا مساعدتي بالمعدات التقنية ، وعرضوا فقط إرسال (على نفقتهم الخاصة) جهاز لهم في الولايات المتحدة الأمريكية للتشخيص والإصلاح.
لم يكن هناك خيار سوى البدء في إصلاح مستقل.
يتم تثبيت Ubuntu على المضيف ، ويتم تضمين بعض الأدوات المساعدة المستخدمة في التوزيع ، وبعضها يتم تثبيته عبر apt.
التفتيش الخارجي
نحن نفكك ، انظر إلى اللوح. على متن الطائرة تقع:
لقد سررت بشكل خاص بموصل UART المهترئ بعناية ، والذي تم تربيته ، علاوة على ذلك ، للحصول على مشط قياسي يبلغ 2.54 مم ، لذلك تم توقيع جهات الاتصال. لم أر هذا منذ فترة طويلة ، بحد أقصى خمس نقاط على اللوحة ، وحتى مع وجود علامات غير مهمة مثل TP1 ، إلخ.
دعنا نبدأ
نقوم بتوصيل USB-UART (لا تنسى المستوى ، فهو 3.3 فولت هنا). نبدأ minicom ، نتلقى:
TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 0 Read boot progress : 0 Write boot progress legacy : 0 Write boot progress : 0 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x60000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 NAND read from offset 60000 failed -74 ** Read error
كما ترى ، فإن التسلسل قياسي تمامًا: يتم تحميل محمل التمهيد الأول (TI UBL) ، ثم U-Boot ، والذي بدوره يقوم بتحميل نواة لينكس.
وفقًا للسجل ، من الواضح أن شيئًا ما حل في فلاش NAND الداخلي ، عندما يتم تشغيل نواة Linux ، لا يتقارب المجموع الاختباري. ومع ذلك ، يمكنك مقاطعة التنزيل ودخول وحدة تحكم U-Boot.
ألق نظرة على الأوامر المتوفرة:
هناك الكثير منهم U-Boot > help ? - alias for 'help' askenv - get environment variables from stdin base - print or set address offset boot - boot default, ie, run 'bootcmd' bootd - boot default, ie, run 'bootcmd' bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo - echo args to console editenv - edit environment variable eeprom - EEPROM sub-system env - environment handling commands exit - exit script false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) go - start application at address 'addr' help - print command description/usage i2c - I2C sub-system iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mdc - memory display cyclic mii - MII utility commands mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mtest - simple RAM read/write test mw - memory write (fill) mwc - memory write cyclic nand - NAND sub-system nboot - boot from NAND device nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage saves - save S-Record file over serial line setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test - minimal test like /bin/sh true - do nothing, successfully usb - USB sub-system usbboot - boot from USB device version - print monitor version
دعنا نرى متغيرات البيئة:
U-Boot > printenv autokern=0x60000 autoroot=/dev/mtdblock3 baudrate=115200 bootcmd=nboot 80700000 0 ${autokern}; run setbootargsnand; bootm setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off stderr=serial stdin=serial stdout=serial ver=U-Boot 2010.12 (May 09 2012 - 13:10:23) Environment size: 338/16380 bytes
أول شيء جربته هو إيقاف تشغيل الشيك والتمهيد باستخدام أوامر U-Boot.
U-Boot > setenv verify n U-Boot > boot
انتقل أكثر قليلاً ، ولكن ليس كثيرًا:
كذلك توقف الجهاز.
يمكن ملاحظة من متغيرات البيئة أن صورة النواة تقع في NAND Flash مع إزاحة 0x60000 ، عند تحميلها ، يتم نسخها إلى العنوان 0x80700000 (وفقًا لخريطة ذاكرة المعالج ، هذه هي مساحة العنوان الخاصة بـ DRAM الخارجية) وتحميلها. حجم صورة النواة ، كما يتبين من السجل ، هو 1236292 بايت. حاولت القيام بذلك يدويًا. نفترض أن الصورة مخزنة بتنسيق uImage ، لذلك نرمي 64 بايت على الرأس ، نحصل على 1236356 بايت = 0x12DD84:
U-Boot > nand read 80700000 60000 12dd84 U-Boot > iminfo
بعد ذلك ، كنت أرغب في ضخ ملف تفريغ الصورة إلى الكمبيوتر للعب به. لم أتوصل إلى أي شيء أفضل من كتابة سجل وحدة تحكم مع إخراج الذاكرة على الشاشة ، ثم تحويله إلى ملف ثنائي.
تشغيل minicom مع تسجيل الدخول:
minicom -C orig-uImage.txt
نعرض محتويات الذاكرة على الشاشة:
U-Boot > md.b 80700000 12dd84
نخرج من minicom ، ونعدل السجل ، ونزيل الخطوط الإضافية ، ونحولها إلى ثنائي:
xxd -r -seek -0x80700000 orig-uImage.txt orig-uImage
كنت أرغب في إعادة حزم الصورة بحيث لا ينتج عنها أخطاء في المجموع الاختباري. احذف أول 64 بايت ، ثم أنشئ صورة جديدة:
mkimage -A arm -T kernel -C none -a 80008000 -e 80008000 -n "Linux-2.6.10_mvl401-xds560" -d orig-uImage patched-uImage
املأ الملف الناتج مرة أخرى باستخدام بروتوكول YModem:
U-Boot > loady
نحاول التمهيد ، ولكن أيضًا تعليقنا في مرحلة تفريغ النواة:
U-Boot > bootm
كان من المتوقع أن يأمل المرء هنا. ولكن على الأقل قاموا بتحميل سير عمل مشاركة الملفات ، ليس سيئًا.
كل ما لدينا هو ملف برنامج ثابت من موقع الشركة المصنعة USB560v2_firmware_5.0.573.0.bin . افترضت أن هذا الملف يحتوي على صورة kernel ، ولكن من المعقول توقع أن الملف مشفر بمفتاح بسيط على الأقل. لذلك ، أعترف ، لقد تعطلت وكتبت إلى الشركة المصنعة طلبًا uImage غير منقطع بحيث يمكنني تحميله على الجهاز والتمهيد منه ، وبعد ذلك يمكنني إعادة تحميل الجهاز باستخدام أداة USB قياسية. حتى أنه أشار إلى شروط GPL (التي يتم بموجبها توزيع Linux) ، والتي بموجبها لن يؤذي توفير رموز مصدر kernel بالإضافة إلى ذلك.
مباشرة بعد إرسال الطلب ، قررت مع ذلك محاولة فك ضغط ملف البرنامج الثابت ، كأرشيف بسيط. وها ، لقد اتضح!
tar -xf USB560v2_firmware_5.0.573.0.bin
بعد التفريغ ، ظهر uImage : uImage و rootfs.tar.gz . ما وصفه الطبيب هو صورة النواة ونظام ملفات الجذر.
يبقى لملء uImage في ذاكرة الجهاز باستخدام YModem والبدء ، وهو ما فعلته. تم تشغيل الجهاز بنجاح في نفس الوضع الآمن ، لقد قمت بتعليقها. دعم الشركة المصنعة ، معتقدةً أنني سأحصل على الجهاز في المرة القادمة ، ذهبت إلى الفراش بهدوء.
السلسلة الثانية
ومع ذلك ، في اليوم التالي كانت تنتظرني مفاجأة غير سارة. توقف الجهاز عن التحميل بنجاح. ما لم أجربه للتو ، لقد حصلت على خطأ:
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
سجل التمهيد الطويل للنواة Starting kernel ... Uncompressing Linux................................................................................. done, booting thelLinux version 2.6.10_mvl2 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: mem=64M console=ttyS0,115200n8 root=/dev/mtdblock3 rw rootfstype=jffs2 ip=off PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 62080KB available (2118K code, 448K data, 136K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok spawn_desched_task(00000000) desched cpu_callback 3/00000000 ksoftirqd started up. desched cpu_callback 2/00000000 desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'nor_davinci.0'. Parent at platform Registering platform device 'nand_davinci.0'. Parent at platform DaVinci I2C DEBUG: 12:46:30 Mar 29 2012 Registering platform device 'i2c'. Parent at platform musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [peripheral] [debug=0] Registering platform device 'musb_hdrc'. Parent at platform musb_hdrc: USB Peripheral mode controller at c4800000 using DMA, IRQ 12 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. yaffs Mar 29 2012 12:46:15 Installing. Registering platform device 'davincifb.0'. Parent at platform Console: switching to colour frame buffer device 90x30 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Registering platform device 'serial8250'. Parent at platform ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize Registering platform device 'ti_davinci_emac'. Parent at platform TI DaVinci EMAC: MAC address is 00:00:00:04:12:64 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. netconsole: not configured, aborting i2c /dev entries driver elevator: using anticipatory as default io scheduler NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Unknown NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging" nand_davinci: hardware revision: 2.1 mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET: Registered protocol family 1 NET: Registered protocol family 17 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000016c: 0xffef instead Empty flash at 0x00a237fc ends at 0x00a23800 Empty flash at 0x00c3b7d8 ends at 0x00c3b800 mtd->read(0x1f320 bytes from 0xec0ce0) returned ECC error mtd->read(0x1fb8c bytes from 0xf20474) returned ECC error VFS: Mounted root (jffs2 filesystem). Freeing init memory: 136K mtd->read(0x44 bytes from 0xf39da8) returned ECC error mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0x44 bytes from 0xed8d20) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00ed8d20: Read 0xa8462b94, calculated 0xa03c90e8 mtd->read(0xa7e bytes from 0xed82a0) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00c3ad78: Read 0x31ac7e30, calculated 0xa52ecb11 jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a22d9c: Read 0x31ac7e30, calculated 0xe9f89c4c mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0xa7e bytes from 0xed82a0) returned ECC error INIT: version 2.85 booting INIT: PANIC: segmentation violation! sleeping for 30 seconds. jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a2ad10: Read 0x5fa921cc, calculated 0x5282f1d9 INIT: PANIC: segmentation violation! sleeping for 30 seconds.
خلصت إلى أن نظام الملفات الجذر قد تضرر أيضًا. حسنًا ، فأنت بحاجة إلى وميضه أيضًا.
أولاً ، اكتب uImage إلى NAND ، حتى لا يتم تحميلها من خلال UART في كل مرة (يجب أن أعترف ، بسرعة 115200 ، يتم تحميل وقت ملحوظ حتى بحجم ميغابايت واحد). عند العمل مع NAND ، في حالة فقط ، نقوم بمحاذاة حجم الصورة مع حجم صفحة NAND لأعلى (لقد قابلت مثل هذه التوصية في مكان ما) ، وحجم الصفحة هنا هو 1024 بايت = 0x800 (انظر السجل الأول).
U-Boot > loady ... U-Boot > nand erase 60000 12DC00 U-Boot > nand write 80700000 60000 12DC00
من سجل تمهيد kernel ، حدد المعلومات المفيدة:
Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging"
لذلك يجب كتابة نظام الملفات الجذر إلى NAND مع إزاحة 0x260000. يبقى فقط أن نفهم بأي شكل. نتذكر متغيرات بيئة U-Boot ، على وجه الخصوص ، هذا الخط:
setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off
لذا ، نحتاج إلى تحويل rootfs.tar.gz بنا ، من ملف البرامج الثابتة ، إلى تنسيق JFFS2. في موجه الأوامر مع Wiki من Texas Instruments ، نقوم بذلك (مطلوب sudo لـ tar ، لذلك يولد أخطاء عند تشغيل الأمر mknod ):
mkdir rootfs sudo tar -xf rootfs.tar.gz -C rootfs mkfs.jffs2 -n -r rootfs -e 16 -o rootfs.jffs2
نقوم بتحميل الملف الناتج في ذاكرة الجهاز ، ثم نسخه إلى قسم NAND المطلوب (يتم تقريب الحجم أيضًا إلى الصفحة):
U-Boot > loady ... U-Boot > nand erase 260000 39f000 U-Boot > nand write 80700000 260000 39f000
نعبر أصابعنا ، وإعادة التشغيل ، حسنًا ، الآن كل شيء على ما يرام بالتأكيد.
سجل كامل طويل جدًا من التنزيل الناجح TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 3 Read boot progress : 10 Write boot progress legacy : 2 Write boot progress : 9 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x1260000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1235632 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000
خاتمة
نعم ، تبين أن الإجراء النهائي ليس معقدًا للغاية ؛ في الواقع ، لا يوجد الكثير من الهندسة العكسية الحقيقية هنا. لكنني شخصياً تعلمت الكثير من الأشياء الجديدة حول الأشياء ذات المستوى المنخفض أثناء عملية التمهيد لنظام Linux المضمن ، وتعلمت كيفية العمل مع وحدة تحكم U-Boot.
لأصحاب بلاك هوك USB560v2يمكن ملاحظة أن الرجال لم يكلفوا أنفسهم عناء الحماية. بعد تشغيل Linux ، تظهر مطالبة في وحدة التحكم لتسجيل الدخول. يسمح لك تسجيل الدخول root بدون كلمة مرور بتسجيل الدخول باستخدام حق الوصول الإداري والقيام بأي شيء باستخدام الجهاز. الأكثر إثارة للاهتمام هو في دليل /usr/local/bin .
لكن هذه قصة مختلفة تمامًا.
اتمنى ان يكون ممتع