Реанимация D-Link NAS DNS-325

Добрый день!

Хочу поделиться историей о том, как я чинил примус свой домашний NAS D-Link DNS-325.

Сам NAS у меня обычно в режиме минимального потребления электроэнергии с выключенными жёсткими дисками WD Green (установлен fun_plug на внешнюю USB флешку, об этой «прокачке» есть статья на Хабре). Однажды, после отпуска, я включил питание на NAS, чтобы просмотреть/загрузить фотографии. Он не включился. Cветодиод питания весело замигал, загорелись индикаторы сотояния HDD, но мигание продолжалось и продолжалось без признаков жизни. При нормальных условиях мигание означает процесс загрузки, который должен завершиться полной инициализацией и установлением стабильного свечения power LED. После многих попыток запустить устройство, отключения жёстких дисков, нажатия кнопки reset (которая, кстати, безполезна пока загрузка не завершится успешно), я с горечью осознал, что это не тривиальная проблема, с которой мне прийдётся справиться самому из-за истёкшей гарантии (12 месяцев).

Осмотр содержимого жёстких дисков через USB-to-SATA показал, что данные в порядке, RAID1 сконфигурирован.

Джедайское гугление дало надежду на подключение к последовательному порту DNS-325 и возможной диагностики. Необходимо подобраться к порту, плата легко достаётся после отключения жёстких дисков и вывинчивания 4-х винтов сзади NAS (шлицы находятся под резиновыми заглушками).

Детали о распиновке UART на плате и способе подключения можно найти здесь. Оставалась одна проблема. UART на плате DNS-325 требует TTL 3.3V и может сгореть при более высоких напряжениях. У меня не оказалось RS-232-TTL 3.3V конвертора, а заказанный кабель на eBay так и не пришёл в срок. Связавшись с продавцом, я получил ответ, мол, видимо, потерялся, бывает. Деньги он вернул, но нужно было искать другой кабель или… На помощь пришла идея использовать завалявшуюся Raspberry PI (или просто Малину), на борту которой есть 3.3V UART.

Возможно, повторюсь, рассказывая о том, как настроить Малину с «нуля», но я сам был бы рад прочитать об этом в одном месте и последовательно.

Настройка Raspberry PI

Так как моя «Малина» была уже в работе, необходимый минимум железа имелся:

• Собственно, сама Raspberry PI;
• Акриловый корпус;
• SD карта;
• Коннектор на GPIO/UART пины, блок питания etc.

Итак, скачиваем готовый образ для SD-карты дистрибутива RASPBIAN с главного сайта www.raspberrypi.org. Далее записываем скаченый образ на SD-карту. В моём случае я использовал встроенный card-reader в ноутбуке и программу Win32DiskImager. По умолчанию сетевой интерфейс в дистрибутиве запрашивает адрес по DHCP, поэтому, подключив Малину к домашнему роутеру, я смог залогинится и сконфигурировать последовательный порт с помощью:

root@raspberrypi:~# raspi-config

Далее навигация по меню: «8 Advanced Options» --> «A7 Serial»:

Would you like a login shell to be accessible over serial? Current setting: yes

Выбираем «No» и перезагружаемся.

Установка и настройка терминала

apt-get install minicom

Запускаем эмулятор терминала для работы с последовательным портом:

minicom -D /dev/ttyAMA0 -b 115200 -8

После того, как соответствующие пины последовательного порта DNS-325 подключены к Raspberry PI, наступает самый долгожданный момент включения устройства. Сейчас, собственно, хоть что-то станет ясно, почему NAS после включения входит в «крутое пике» и не подает признаков жизни. Скорость порта и прочие настройки установлены верно, само устройство оказалось «живым» и в консоли Малины побежал лог загрузки.
Раскрыв спойлер, можно увидеть весь лог загрузки:

Для доступа в shell необходимо ввести код 5784468.
После беглого осмотра в консоли стало ясно, что NAS загрузился в single-user mode. Ничего не смонтировано кроме корневой системы.
Очевидно, что процесс загрузки не продолжается именно из-за проблем с монтированием основного файлового дерева из squash образа:
SQUASHFS error: Major/Minor mismatch, trying to mount newer 4.0 filesystem
SQUASHFS error: Please update your kernel
mount: wrong fs type, bad option, bad superblock on /dev/loop0,

Сам файл, в котором squash образ, выгружается из внутренней flash в файл /usr/local/tmp/image.cfs с помошью nanddump.
mount -o loop /usr/local/tmp/image.cfs /mnt приводило к такой же ошибке, что и при загрузке.

Первое, что приходило в голову, была мысль о возможном повреждении самого image.cfs во flash памяти. Но очередного просмотра лога загрузки я обратил внимание на сообщение об ошибке, которое изначально затерялось в длинном тексте лога:
Image Name: Linux-2.6.31.8
.....
Verifying Checksum ... Bad Data CRC

После чего U-Boot грузил образ другого, более старого ядра: Image Name: Linux-2.6.22.18

NAND read: device 0 offset 0x7100800, size 0x500000
load addr ....  =a00000

 5242880 bytes read: OK
## Booting image at 00a00000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2011-05-25   7:23:15 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2214860 Bytes =  2.1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK

Забегая вперёд, хотелось бы отметить, что область "mini firmware" внутренней flash, откуда загрузился образ с ядром в аварийном режиме, по-видимому, предназначена для подобных ситуаций. Если бы у меня стояла более ранняя прошивка, загрузка бы прошла успешно и я бы и не узнал о повреждении. Но в прошивке 1.04 новое ядро 2.6.31.8 и поэтому монтирование образа сжатой файловой системой (опять же, нового формата) на старом ядре завершалось ошибкой.

Гугление не дало готового решения, но вдохновило на jugaad, а именно: используя возможности U-Boot перезаписать uImage образ во внутренней flash памяти с помощью вырезанного образа из стоковой прошивки.

Достаём образ uImage с ядром из прошивки

Скачиваем стоковую прошивку с сайта D-Link: DLINK_DNS325.1.04b05 (на тот момент у меня стояла именна эта версия).
Каким-то образом необходимо было достать образ с ядром и попробовать перезаписать в повреждённую область.
Очень полезным инструментом оказался binwalk:

Вырезанный uImage образ попробуем записать во внутреннюю flash память начиная с адреса 0x100000.

Установка и настройка Kermit

Для того, что передавать бинарные файлы в U-Boot нам понадобится достаточно древний протокол Kermit.

apt-get install ckermit

Создаём .kermrc с таким содержимым:

set line /dev/ttyAMA0
set speed 115200
set carrier-watch off
set handshake none
set flow-control none
robust
set file type bin
set rec pack 1000
set send pack 1000
set window 5

Загрузка расширенного U-Boot

Чтобы попасть в U-Boot командную строку, необходимо успеть прервать процесс загрузки нажав Пробел и «1» в момент, когда в консоли minicom на эту операцию отводится 2 секунды:
PEX 0: interface detected no Link.
Net: egiga0 [PRIME]
Hit any key to stop autoboot: 1

К сожалению, я не обнаружил в стоковом U-Boot команды loadb <addr>, которая позволяет загружать бинарный файл по указанному адресу в памяти.
Поэтому прийдётся скачать и сконфигурировать утилиту для загрузки расширенного U-Boot через последовательный порт.

Необходим компилятор для сборки на Малине:
apt-get install gcc

Скачаем U-Boot:
git clone -b dns320_support https://github.com/lentinj/u-boot.git
Собираем:
make distclean && make dns325_config && make u-boot.kwb

(Если вы подключились с помощью кабеля USB-Uart-TTL и производите сборку на x86 платформе, необходимо установить ARM-компилятор: export CROSS_COMPILE=arm-linux-gnueabi-)

Запускаем утилиту для передачи U-Boot:
root@raspberrypi:~/u-boot# cd u-boot
root@raspberrypi:~/u-boot# ./tools/kwboot -p -b u-boot.kwb -B115200 -t /dev/ttyAMA0
Sending boot message. Please reboot the target.../

Всё готово к передаче, выключаем NAS, ждём 10 с, включаем и следим за процессом передачи u-boot.kwb.
Процесс займёт несколько минут. В консоле вы сможете видеть процесс передачи в виде бегущих точек.
По окончании передачи необходимо прервать загрузку в момент Hit any key to stop autoboot: 4 (см. выше).
Выйдем из программы с помошью Ctrl+/ затем «c»

Передача образа и запись во flash

Запускаем kermit на Малине и инициируем передачу файла uKernel, который мы вырезали ранее из прошивки:
root@raspberrypi:~# kermit
и переходим в режим коесоли последовательного порта:

(/root/) C-Kermit>connect
Connecting to /dev/ttyAMA0, speed 115200
 Escape character: Ctrl- (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------

Здесь, в командной строке U-Boot, даём команду на приём файла по адресу 0x000000 (загружаем мы временно для перезаписи, поэтому базовый адрес не важен):

=> loadb 0x00000000

U-Boot переходит в режим ожидания файла, а мы выходим в командную строку Kermit нажатием Ctrl+ и «c» и передаем файл:

(/root/) C-Kermit>send uKernel

Через несколько минут файл передан и готов к записи во flash:

=> nand erase 0x100000 0x300000 — Очистка flash области 0x100000-0x300000
=> nand write 0x000000 0x100000 0x300000 — Запись из памяти со смещением 0x000000

ВСЁ… можно перезагрузиться.
NAS успешно загрузился с установленными дисками и USB флешкой как ни в чём не бывало.
Для перестраховки я загрузил последнюю версию прошивки стандартным путём через страничку управления.

P.S. Подобные операции с U-Boot и перезаписыванием внутренней flash я производил впервые, поэтому остаётся открытыми вопросы эффективности описанных выше шагов. В частности, я не смог найти ответы или проверить:

1. Что произошло и как этого избежать в будущем?
2. Реальный размер uImage образа существенно меньше считываемого U-Boot'ом размера 0x300000;
3. Использование tftp для передачи образа uImage;
4. Использование USB flash для загрузки образа uImage (в расширеном U-Boot есть возможность инициализации USB);
5. Бэкап разделов внутренней flash памяти на внешнюю USB память.

Автор: wwwalex

Источник