DipSpb
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Хочу рассказать о своих экспериментах с обсуждавшейся в этой ветке платформой. Здесь, похоже, было наиболее живое сообщество энтузиастов, так что, возможно, кому-то будет интересно (с исторической точки зрения). Или чем-то поможет в качестве необычного опыта выходного дня. Тема конечно старая, давно эти устройства мало-актуальны, но ... Попался мне в руки один из клонов на такой же платформе, который не меньше 8 лет лежал у людей на полке без дела. Явно, использовать по назначению его уже никто не собирался и его ожидала мусорка! Стало жалко - коробочка симпатичная, я решил с ней "поиграть": запустить чистый Debian, посмотреть, что может эта старая arm-платформа. Но запускать Debian с помощью chroot мне почему-то показалось не интересным, и захотелось подключать RootFS непосредственно с раздела EXT2/3 жёсткого диска прямо во время запуска системы. Пришлось припаять и подключить UART (распиновка у меня была аналогичной этой платке, хотя сама плата немного иная), слить дамп всей Flash-памяти (на всякий случай), после чего стало возможно пробовать запускать разные версии прошивок и ядер Linux. Если бы устройство было в точности, как обсуждалось в этой ветке (NSB3AST / NSB3AS / NSB3AS1T), то я, наверное, (наигравшись) не стал бы рассказывать о своих экспериментах (ничего интересного нет в том, чтобы повторить действия по старым инструкциям и получить предсказуемый результат), но мне попался некий клон с наклейкой "CHRONOS" с гордой надписью "Mobile LAN Disk" (именно так, без какой-либо ссылки на номер модели). Поиски в интернете выявили его "оригинал" (он назывался "ATEC CNS2132") и точного брата-близнеца от компании Premiertek ED-35-LANII-SA и ещё одного от компании Multicase: NS-348s (на сайте последнего до сих пор доступна официальная прошивка и даже какой-то SDK с исходниками!). Внутри коробочки обнаружилась плата с процессором STR8132 (он же CNS2132) и всё те же 8 Mb Flash + 32Mb RAM, что и привело меня в эту старую ветку форума. Но, несмотря на очевидное аппаратное сходство, в этой коробочке были и некоторые отличия, существенные с точки зрения "альтернативных прошивок": внутренний SATA-порт был реализован как-то хитро, и судя по всему не так, как у других моделей на этой платформе (См. подробнее ниже). И так, мне непременно хотелось обеспечить монтирование RootFS непосредственно со вставленного SATA-диска, без всяких chroot! Т.к. навязывание своих bootargs (через u-boot) в штатном ядре не было разрешено, пришлось искать другие варианты, и изучение темы быстро привело меня на сайт TinyHack, где человек специально собрал ядро Linux для этой платформы с поддержкой монтирования RootFS с подключённого диска. Но тут меня ждало первое разочарование. Ни одно из четырёх найденных там ядер не захотело стартовать на моей коробочке. Увы, автор тех сборок отключил вывод в консоль сообщений о ходе загрузки, так что выяснить, на каком этапе там всё висло, мне не удалось. Могу только сказать, что до инициализации USB дело точно не доходило. Вторая попытка была сделана с вариантом ядра, собранного авторами SnakeOS. Саму их систему я пробовать не стал (у меня не было задачи получить классическую функциональность с WEB-интерфейсом), но у них в архивах нашёлся файлик bootpImage.8132, предназначение которого в рамках их проекта мне понять не удалось. Этот файл содержал хитрый вариант ядра, поддерживающий монтирование RootFS с диска, и он у меня запустился ! Но радость была не долгой… быстро стало ясно, что это ядро "видит" диски только на внешнем USB-разъёме, а диск на внутреннем SATA-USB не видит ни в процессе инициализации, ни уже после (когда система успешно загрузилась с внешнего USB). Т.к. всякие lsusb там корректно не работают (вероятно из-за того, что при компиляции ядра не включили DEVTMPFS), то понять суть проблемы не просто... Я тогда предположил, что это ядро от SnakeOS почему-то не понимает USB-SATA адаптер, используемый в моей коробочке или "криво" инициализирует встроенный USB-хаб, из-за чего работает только один USB-порт. (Оба предположения, как выяснилось позже, были не верны). Можно конечно было подключить внутренний SATA-USB внешним кабелем к другому порту USB (даже паять ничего не нужно, просто использовать кабель от USB-принтера), но ... это как-то "не спортивно" :-) На этом этапе я уж было задумался о том, чтобы самому скомпилировать ядро под эту платформу, но что делать с вышеупомянутыми исходниками с сайта Multicase было не ясно, а упоминаемый везде сайт codesourcery.com (откуда народ получал документацию и кросс-компилятор) в старом своём виде уже не доступен. Выяснилось, однако, что OpenWRT в своей редакции barrier_breaker официально поддерживал нашу платформу (правда называя её cns21xx). Пробившись через квест устаревших ссылок и отправленных в архив версий исходников, мне удалось скомпилировать ядро Linux 3.10.49 от OpenWRT, и оно даже начинало грузиться, но ... опять же видело только один USB-порт, и даже с него так и не смогло подцепить раздел RootFS c EXT2/3 раздела на диске: sda1 на горизонте появлялся, но так и не монтировался, хотя все нужные поддержки файловых систем в конфигурации ядра были включены (если кому интересно, можно это пообсуждать, но не уверен, что это сколько-нибудь актуально, да и уже больше относится к сборке OpenWRT, чем к этой теме). Забегая вперёд - решить проблему потом всё-таки удалось, но это было уже много позже! И так, на тот момент все штатные попытки подключить RootFS напрямую с диска (без использования chroot) не увенчались желаемым успехом (как при использовании готового ядра Linux с сайта TinyHack и проекта SnakeOS, так и собранного самостоятельно по инструкции OpenWRT). Когда все "штатные" методы были исчерпаны, мне пришло в голову посмотреть, а где и как в готовом образе ядра системы собственно хранится строка с параметрами загрузки (в частности, путь к устройству, откуда надо монтировать RootFS). Оказалось, что после распаковки z-image, там эта строка элементарно отыскивается HEX-редактором! Идея сработала: я взял "распотрошил" последнюю штатную прошивку V01R17, отделил z-image c ядром, откорректировал HEX-редактором строку запуска c 'root=/dev/mtdblock3' на 'root=/dev/sda1 rootdelay=15', запаковал всё обратно и прошил в соответствующий mtdblock. Debian успешно грузится, всё работает и даже за пару часов обновилось штатными методами до Lenny (новее уже не получится из-за архитектуры платформы). Да, ядро осталось "штатным" (старым), но это не мешает Debian Lenny относительно нормально функционировать. Единственная проблема - это ядро не справляется с переполнением крохотной памяти (той, что 32Мб). И подключенный swap не сильно спасает положение. Но если не насиловать устройство заливкой на него гигабайтных файлов по SMB, то всё работает достаточно стабильно. Наверное, можно даже поставить простенький WEB-сервер (чисто для себя, без фанатизма) или поднять старенькую версию Asterisk (опять же для домашних нужд). Но это уже отдельный разговор. Если кому интересна процедура "потрошения" прошивки и распаковки / запаковки z-image, могу рассказать подробнее. | Всего записей: 24 | Зарегистр. 14-03-2018 | Отправлено: 07:37 03-10-2019 | Исправлено: DipSpb, 06:02 24-01-2020 |
|