Тег ‘миникс’

Месье знает толк в извращениях

Поставил на одном ноутбуке Ubuntu 11.10, Minix 3.1.8 и Minix 3.2.0. Для загрузки всего этого зоопарка пришлось столкнуться с настройкой grub в его версии из Ubuntu. В моем личном рейтинге наиболее отвратительно конфигурируемых программ grub 1.99 занял первое место.

От убунты впечатления странные. В принципе, в плане “включи и работай” – система достаточна неплохая, а вот в плане “конфигурируемости” – это что-то странное. Например, я нигде не нашел какого-то подобия Device Manager из винды. Настройки ужасно минималистичны, местные “Параметры системы” не дотягивают даже до “Панели управления” в Windows 95. Понятно, что для всего, что надо, есть текстовые конфиги – но расчет, видимо, делается на то, что юзверь туда не полезет – это еще более страшные дебри, чем реестр Винды.

Гибрид AppStore и synaptic – очень “интересная” находка, еще раз подчеркивающая, что от системы пакетов до концлагерных порядков в AppStore – один шаг. То же самое сказать и о “свободе” Linux – в самых продвинутых дистрибутивах она превращается в “шаг влево, шаг вправо – расстрел”.

В общем, Ubuntu имеет такое же отношение к Linux, как MacOS X к Mach. Плохо это или хорошо – решать вам, хотя читать статьи линуксоидов на тему “Шаттлворт – мудак” довольно забавно.

PS Интересно, как лечатся серьезные глюки Ubuntu? Видимо, универсальный способ – переустановка, как и для Windows :)

Новости про Minix

Вот уже больше года “стабильной” версией Minix остается 3.1.8. 3.2.0 так и не выходит из экспериментальной стадии, хотя сделано там очень и очень много. Наконец появилась поддержка динамических библиотек, основной формат объектных файлов – ELF, а не устаревший a.out, портируется userland из NetBSD, список пакетов наконец-то “перерос” версию 3.1.7. Таненбаум опубликовал вакансию программиста для ARM – Minix будут туда портировать. В общем, жизнь движется.

Интересно, можно ли собрать в нынешнем Minix 3.2.0 библиотеку Qt?

А я тем временем достал с пыльной полки бывший ноутбук брата, поставил там Minix 3.1.8 и решил вернуться к вогоплееру. По собственной же инструкции попытался собрать u-boot, использовал все те же binutils 2-16.1 и gcc 3.4.6. Если сами по себе они собрались нормально, в соответствии с инструкцией, то вот с u-boot произошло что-то непонятное.

Во-первых, он затребовал у меня заголовочные файлы из директории ./gcc/3.4.6/i686-pc-cygwin/includes – или что-то в этом духе. Это происходило еще на этапе сборки “утилит” типа bmp_logo, и занимался этим еще “родной” gcc. Я сначала немного офигел. В Minix 3.1.8 gcc иногда безбожно “тупит”, так как прикручен к системе немного нестандартно, но используется все-таки версия 4.1.1, а “старая” 3.4.с чем-то может быть “доустановлена” из пакетов. Я сначала подумал, что возникли какие-то проблемы с “системными” библиотеками и заголовочными файлами – при их сборке ОС думает, что их надо положить в директорию для gcc 4.1.1, а gcc считает, что их надо искать в директории для другой версии.

Правда, посмотрев чуть-чуть повнимательнее, я обнаружил там упоминание cygwin и понял, откуда притащил бяку. Кроме того, слова Missing dependency уже не оставляли сомнений – “корни” ошибки растут из оставшихся в архиве с исходниками u-boot файлов .depend. Добавил в make clean команду на удаление этих файлов – и процесс пошел. В общем, что я там писал?

gmake volans_nand_config
gmake

Да как бы не так! Все остановилось с руганью на 95 строчку файла ./nand_spl/board/volans/start.S – якобы там junk after end of line, недостача скобок, ад и погибель. Строчка сама по себе вполне законная, что-то типа

.word SOMETHING_DEFINED_BEFORE

Пришлось немножко изучить, как gcc вызывает ассемблер. Оказывается, GNU as препроцессора не имеет и файлы с расширением .S сначала обрабатываются встроенным в gcc препроцессором по правилам Си, а затем передаются ассемблеру. Решил просто “препроцессировать” этот файл – как я понял, ассемблер ругается только на свой ввод. Может, там чего криминальное на 95 строке?

Препроцессировал, получил файлик в 50 с чем-то строк – и на что же ругаться? А при попытке ассемблировать его ругань вполне себе была. Правда, в комментариях специального вида было прописано, что и из какого файла взято. 95 строке start.S соответствовала такая, тоже вполне невинная:

.word ((2048==2048)&0xff0000) | ((2048!=512)&0xff00) | ((3==3)&0xff)

Но если эту строку закомментировать – то все работало! Точно так же, “вычеркивая” отдельные конструкции, я обнаружил, что причиной ругани была операция !=. Закомментировав “второй” блок, я получил “законный” start.s – но меня все же мучило, что же должно оказаться на месте (2048!=512), чтобы его можно было применять в побитовых операциях. Начал искать всякие руководства по GNU Assembler – и обнаружил, что операции != там не предусмотрено, а неравенство записывается в виде <>. Если неравенство верно, то на его месте в выражении окажется -1, если неверно – то 0. Заменив в определении SOMETHING_DEFINED_BEFORE != на <>, я получил заведомо правильный ассемблерный код.

Что интересно – при сборке pavo_nand_config ругани не возникало. Скорее всего, в своей инструкции тогда я наврал – либо в версии binutils, либо в том, что собрал работоспособный u-boot для volans. Для pavo – да, а вот вогоплееровский u-boot я не проверял.

В общем, вчера вечером что-то собралось, а сегодня я решил посмотреть, оно вообще запускается или нет. Достал чудо дизайнерской мысли, сдул с него пыль, подключил к компьютеру и даже успешно прошил. Включил, и что удивительно – “оно” заработало, включило экран и даже что-то там написало. А вот в консоль по RS-232 сыпался форменный бред. Правда, “туда” буковки уходили, и даже hello_world из комплекта u-boot оказался рабочим. В общем, явно происходило что-то странное.

Я уж было грешил на компилятор – чего он там мог соптимизировать, тем более, что в подобного рода “низкоуровневых” делах сплошь и рядом встречается, что компилировать надо одним-единственным рекомендованным компилятором, а все остальные попросту “компилируют” какой-то бред. Правда, мне показалось, что наличие и отсутствие бреда как-то связано с “втыканием-вытыканием” разъема. Решил проверить свои подозрения – и обнаружил, что проводок от UART к плате отвалился и лежит на ножках процессора – вот отсюда и идет этот “бред”.

В общем, паять лучше надо. Ну а в целом – я более-менее восстановил toolchain на ноутбуке с Миниксом, так что можно и дальше “играть” с плейбоеплеером, не заморачиваясь неудобствами cygwin (потому что он действительно ужасен).

PS В cygwin u-boot компилируется полчаса, в Minix – за минуту.

Миникс и USB

Кстати, говорят, что в Миниксе версии 3.2.0 появилась поддержка libusb. Надо будет поставить и попробовать собрать JZboot. Были бы драйвера для какого-нибудь USB-RS232 адаптера – было бы совсем хорошо.

Собираем toolchain для MIPS

Как конченый китаефоб, я попросту не доверяю тем toolchain-ам, которые можно скачать с сайта Ingenic. А как вымирающий миниксовод, просто-таки обязан использовать для разработки Minix.

На самом деле, правда, я решил использовать ноутбук с миниксом как машину для разработки по одной простой причине – Minix 3 сейчас представляет собой довольно странную систему с точки зрения набора средств разработки. Например, make в миниксе – это вариация на темы BSD make, а входящий в Cygwin (под которым я хотел работать сначала) GNU make не понимает “позаимствованные” из NetBSD makefile-ы ядра Minix. Собрать BSD make в Cygwin у меня не получилось, там есть какие-то нюансы, так что я решил портированием миникса заниматься на нем самом.

Естественно, что фирма Ingenic не подозревает о существовании такой ОС и “готовый” toolchain для него не выкладывает. Тем хуже для них, потому как компилятор и утилиты для MIPS ничего особо страшного не представляют. Я решил действовать по инструкции с linux-mips.org. Пока что я собрал только binutils и GCC, перспективы использования отладчика пока туманные (так что все дальнейшее превращается в некую авантюру). Успокаиваю себя тем, что в Minix 3 приличного отладчика тоже никогда не было, и ничего, живут люди.

Итак, для начала скачиваем рекомендованные на сайте версии binutils (2-16.1) и GCC (3.4.4). Думаю, что binutils можно и посвежее, а вот с выбором GCC лучше не торопиться. То, что другие называют “бета-версией”, разработчики компилятора GNU считают самостоятельным релизом. Например, в магистерской работе Ингмара Альтинга про портирование Minix 3 на PowerPC специально обращается внимание, что GCC 3.4.6 нормально компилирует MinixPPC, а 4 версия (4.x.x) жестко косячит.

Перед сборкой определим некоторые переменные окружения.

export WDIR=/tmp
export TARGET=mipsel-unknown-linux-gnu
export PREFIX=/usr/local/mipseltools
export PATH="${PATH}":${PREFIX}/bin

Говорят, что в качестве $TARGET можно безболезненно использовать сокращенную запись того же самого – а именно, mipsel-linux, но я не проверял. Вообще, эта строка строится по правилу архитектура-компания-ядро-ОС или иногда – архитектура-компания-ОС, например, mips-sgi-irix6.

Для начала собираем binutils. Тут все без сюрпризов. Распаковываем, конфигурируем, собираем, устанавливаем.

tar xjf binutils-2.16.1.tar.bz2
mkdir build-binutils && cd build-binutils
../binutils-2.16.1/configure --target=$TARGET --prefix=$PREFIX
gmake
gmake install
cd ..

Обращу внимание, что вместо make надо вызывать gmake, в случае с binutils все прокатывает, а с gcc возможны ошибки из-за различия синтаксиса Makefile-ов.

C gcc придется немного повозиться. Во-первых, configure неверно определяет возможности системы, во-вторых, встроенные типы Minix конфликтуют с некоторыми локальными для gcc определениями. Итак, распаковываем и конфигурируем.

tar xjf gcc-3.4.4.tar.bz2
mkdir build-gcc-bootstrap && cd build-gcc-bootstrap
../gcc-3.4.4/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c --without-headers --with-gnu-ld --with-gnu-as --disable-shared --disable-threads

В файле gcc/auto-host.h убираем определения HAVE_GETRLIMIT и HAVE_MMAP_FILE. Кроме того, надо временно закомментировать в файле /usr/include/minix/types.h определение типа block_t. В одном из модулей gcc определяется собственный тип с таким же названием, не имеющий никакого отношения к блокам файловой системы Minix. После этого -

gmake
gmake install
cd ..

Работоспособность всей получившейся хрени можно проверить, собрав u-boot. Все очень просто – скачиваем его с VoGeeky (а можно, кстати, поставить git). Правда, придется поправить Makefile. Вместо конструкции

ifeq ($(ARCH),mips)
CROSS_COMPILE = mipsel-linux-
endif

пишем

ifeq ($(ARCH),mips)
CROSS_COMPILE = mipsel-unknown-linux-gnu-
endif

Теперь можно собирать (естественно, не забыв, что путь к тулчейну был добавлен в $PATH):

gmake volans_nand_config
gmake

После этого компилятор поработает-поработает и выплюнет вполне работоспособный загрузчик. Правда, придется перекинуть его на другую машину, чтобы засунуть в плату – дело в том, что в Minix то ли нет поддержки USB, то ли она в зачаточном состоянии. Соответственно, jzboot запустить не удастся. Ну а как перекидывать файлы – прекрасно написано в руководстве по сетевым возможностям Minix 3.

Экскурсия по исходникам MINIX 3

Что-то я не возвращался к теме запуска разных извращенных ОС на разном извращенном железе, впрочем, на то были свои причины. Если кто еще помнит, я грозился начать портировать MINIX 3 на вогоплеер. Разобрался с toolchain, собрал “железку” – и на этом надолго остановился. Сейчас появилось немного свободного времени, поэтому я и решил написать немножечко о том, что мне предстоит.

В качестве базовой версии я взял MINIX 3.1.8 r8398 – стабильную на начало марта версию. Все дальнейшие разговоры будут вестись именно о ней. Сразу предупрежу (или напомню), что пишу я “для себя”, поэтому все эти очень заумные тексты могут содержать кучу намеренных ошибок и/или искренних заблуждений :)

Итак, каждый, кто установил Minix, или хотя бы загрузился с его компакт-диска, может увидеть там директорию /usr/src, в которой и собраны все исходники ОС. Пробежимся по поддиректориям.

benchmarks – разнообразные тесты производительности. Не трогаем.
boot – начальный загрузчик ОС. Очень специфический, предназначен исключительно для IBM PC-совместимых компьютеров. Я планирую использовать вместо него U-Boot.
commands – исходники программ стандартного POSIX-окружения. Предполагаю, что вполне себе кроссплатформенные. Без наличия работающего ядра и серверов бесполезны, не трогаем.
docs – два несчастных текстовых файлика.
drivers – драйверы различной периферии. Абсолютно необходимы из них драйвер консоли (tty), RAM-диска (memory), и системного журнала (log). Остальные отвечают за всякую ерунду – аудио- и сетевые карты, разного рода дисковые интерфейсы и прочую фигню, существующую исключительно на PC.
etc – эта директория превращается в /etc “работающей” системы. В основном содержит конфигурационные файлы. Некоторые из них отражают загружаемые драйверы и сервисы – соответственно, они должны приводиться в “актуальное” состояние. В общем, исправлять по необходимости.
include – разнообразные заголовочные файлы, в основном – стандартная библиотека Си, но есть одна очень важная поддиректория minix. Как нетрудно догадаться, содержит специфичные для Minix определения. Беглый взгляд на нее показывает, что многие файлы там не менялись с 1990-х годов, и в них предусмотрено существование трех различных архитектур. В других, более новых файлах, встречаются x86-специфические вещи. За этим надо внимательно проследить. Кроме того, нельзя забывать про директорию arch, появившуюся сравнительно недавно и предназначенную для “архитектурно-зависимых” вещей.
kernel – видимо, большая часть работы будет происходить именно тут. Это и есть ядро системы, и именно его придется запускать первым. К счастью, объем его не очень велик, и немалая часть кода в нем “переносима”. Архитектурные зависимости вынесены в поддиректорию arch (возможно, лишь частично). Судя по коду, сделаны попытки “архитектурно-зависимые” части сделать условно-компилируемыми.
lib – всевозможные библиотеки – от libc до какого-нибудь libaudiodriver. Возможно, что придется довольно серьезно “ковырять” некоторые из них, в первую очередь – libc. Это не радует.
man – страницы документации. Не трогаем.
servers – серверы, они же – службы. Большинство из них необходимы для работы системы. Правда, по опыту мужичка, портировавшего MINIX 2.0.4 на самопальный процессор, они достаточно переносимы. Вторая после ядра часть системы, над которой придется работать.
share – интерес представляет поддиректория mk, в которой лежат некоторые makefile-ы, честно упертые разработчиками Minix из NetBSD. Сразу обращу внимание, что эти файлы немного подправлены, например, во многих явно указана архитектура i386 – а нам надо mipsel. Надо разобраться с их содержимым и при необходимости исправить и дополнить.
test – тесты, показывающие работоспособность POSIX-системы. Разумеется, переносимые, и трогать их не надо.
tools – разного рода вспомогательные утилиты для сборки загрузочного образа. Естественно, что предназначены только для PC.

Дополню это небольшим отступлением по поводу истории MINIX. Первая версия этой ОС была написана Энди Таненбаумом, когда фирма AT&T увидела, что разработанная ее специалистами операционная система UNIX превратилась из игрушки в “продаваемый” продукт. После этого исходники UNIX были “закрыты”, а преподавание традиционного для американских университетов курса по архитектуре ОС превратилось в “сухое плавание”. MINIX – это Mini-UNIX, то есть внешне похожая на тогдашний UNIX операционная система, но работавшая на сравнительно дешевых IBM PC. Эта версия прилагалась к первому изданию книге Таненбаума “Операционные системы: разработка и реализация”, вышедшему в 1987 году. В начале 90-х MINIX активно дорабатывали, а Таненбаум активно “отпихивал” все предлагаемые изменения, утверждая, что хочет сохранить исходный код ОС компактным и доступным для изучения. Собственно, благодаря такой позиции Таненбаума и родился Linux – там “отцы-основатели” включали в ядро все предлагаемые нововведения. В 1991 году вышла версия MINIX, позже получившая индекс 1.5 – в ней появилась поддержка других процессоров (Motorola 68000 и SPARC) и основанных на них популярных тогда “персоналок”. Второе издание учебника Таненбаума тоже включало в себя MINIX, но, разумеется, версии 2. В нем исчезла поддержка процессоров Motorola, а x86 и SPARC остались.

Современная версия MINIX, MINIX 3, была анонсирована в 2005 году. Изначально – это существенная переработка MINIX 2.0.4, выполненная студентом Таненбаума Йорритом Хердером (Jorrit Herder) в его дипломной работе. В третьей версии из пространства ядра вынесено все, кроме самых важных компонент (даже управление памятью и приоритетами процессов теперь выполняются в user-space). Тем не менее, после чтения тезисов Хердера (Towards a True Microkernel Operating System) явно прослеживается преемственность между версиями.

Эта преемственность мне явно пригодится – один из “отчетов” о портировании MINIX на новую для него архитектуру написан о версии 2.0.4. Я его уже упоминал, приведу ссылку еще раз:

http://www.homebrewcpu.com/minix_port.htm

Кроме того, нельзя не упомянуть и о том, что в 2006 году Ингмар Альтинг (Ingmar Alting) запустил Minix 3.1.1 на MacBook (с процессором PowerPC) – к сожалению, сделанные им изменения не вошли в “основную ветку” ОС (хотя некоторые “следы” остались). В общем, читаем его тезисы под названием “MinixPPC – a port of the MINIX OS to the PowerPC platform“. Собственно, они объясняют многие отличия нынешнего кода MINIX от того, который описан в книге. Кроме того, они могут послужить своего рода “руководством к действию”.

В общем, ситуция пока складывается такая: в MINIX вплоть до “книжной” версии 3.1.0 последовательно сокращали количество возможных архитектур, в конце концов дойдя до одной только x86. Мало кто занимался адаптацией MINIX под другие машины, так что намеки на SPARC и Mototrola 68000 в заголовочных файлах – это “привет из 1997 года”. Видимо, больше всего в направлении к портированию MINIX сделал И. Альтинг, выделивший в версии 3.1.1 архитектурно-зависимые части. Благодаря его работе в исходниках MINIX в некоторых местах появились директории arch. Их содержимое, разумеется – предмет для дискуссий. Возможно, что придется выносить туда что-то большее, чем “углядел” Альтинг.

Когда руки дойдут до Minix и его исходников в следующий раз – попытаюсь сделать две вещи: настроить систему компиляции (внеся некоторые изменения в Makefile-ы) и определить, какие различия между MIPS с одной стороны и PowerPC вместе с x86 придется учитывать.

Пляски с бубном

Ну что, граждане линуксоиды, сколько надо плясать с бубном, чтобы поставить в этих ваших линуксах тривиальный X-сервер? Говорите, уже не надо? Ну че, молодцы, возьмите с полки пирожок.

А вот сейчас – вопрос настоящим тру-юниксоидам, прожженным знатокам X-сервера (в варианте X.org 6.8.2). Итак, имеется: ноутбук Asus Z99Le, одна штука. На ноутбуке установлен Minix 3 и порт X-сервера для него. В миниксовской консоли прекрасно работают как USB-клавиатура, так и “штатная” ноутбучная. В иксах ноутбучная клавиатура не работает, но работает USB-шная (которая распознается BIOS-ом, “родной” поддержки USB в Minix пока нет). В xorg.conf используется стандартный клавиатурный драйвер kbd, тип клавиатуры – pc101 (стандартная клавиатура).

Ну что, давно такого не видали? И чем тогда ваши Линуксы отличаются от простых виндов, если все работает “из коробки”?

Настоящее радиолюбительское

Сегодня речь пойдет о том, как писать свои (вах!) программы для быдлодевайса, более известного, как вогоплеер. Внимательные читатели моего блога помнят, что я обещал продолжить ковырять его в феврале, так что пора бы и написать что-то осмысленное.

Итак, я съездил на Митино, купил MAX3232, и даже два раза сделал небольшую платку-адаптер. Стандартная схема включения микросхемы MAX232 и ей подобных хорошо известна, и останавливаться на этом я не буду.

Немножко больше я напишу про местонахождение выводов UART на воговской плате. Если Tx хорошо виден и находится на контактной площадке между процессором и флешкой, то Rx нашли не все и не сразу. Как оказалось, эта нога UART-а объединена с левым контактом кнопки K1. Но это еще не все! Для нормальной работы последовательного порта надо еще и демонтировать конденсатор над кнопкой K3. Про это все подробно написано на гуглосайте VoGeeky в специальном разделе, посвященном UART.

Запаяв все соединения между платой плеера и адаптером, и вдоволь наругавшись на говенный спиртоканифольный флюс (все остальное, как назло, закончилось), я приступил к более приятным занятиям. Да, сидеть за компьютером и с умным видом пялиться в экран гораздо лучше, чем согнувшись в три погибели с лупой пытаться припаять провод в полтора квадрата к малюсенькой площадке сорокаваттным паяльником :)

Первым делом надо собрать U-Boot и примеры для него под нашу плату. К сожалению, редакция журнала Vogue не озаботилась тем, чтобы выложить где-нибудь конфиги U-Boot для этой платы, поэтому приходится использовать версию для китайской демо-платы Volans. Итак, используя настроенный toolchain, выполняем в директории с исходниками U-Boot (а где его взять, все уже знают) команды

make volans_nand_config
make

Пока U-Boot собирается, держим пальцы крестиком или пьем кофе – в общем, развлекаемся, как можем. По окончании “сборки” получаем все в той же директории файл u-boot-nand.bin, который надо “прошить” в устройство.

Для прошивки можно воспользоваться швейной машинкой Зингера, а можно – прошивальщиком USBboot китайского производства. И что характерно, прошивальщик работает только под Windows, да еще и 32-битным. Кто там советовал поставить “для разработки” Linux? Берем прошивальщик все на том же VoGeeky, в разделе “Прошивка ядра”.

Теперь – физкультминутка! Одной рукой берем плату плеера и зажимаем на ней кнопку K1, второй рукой (помогая себе ногами и другими конечностями) подключаем USB-кабель к плееру. Получилось? Windows обнаружила неизвестное устройство с названием типа JZ4750 Boot Device? Молодцы!

После небольшой разминки устанавливаем драйвер. Если вы – пресловутый “опытный пользователь” Windows, то укажите установщику драйверов путь к файлу Usb_Boot_Driver.inf из комплекта USBboot. Если вы не понимаете, что написано в предыдущем предложении – зачем вы досюда дочитали? Дальнейшее можно смело прокручивать :)

Теперь, когда установлен драйвер устройства, можно смело запускать Test_jz4740_usb.exe, подкинув к нему в папку u-boot-nand.bin. Откроется окошко для ввода команд, в котором ничтоже сумнящеся вводим следующее:

boot 0
nerase 0 4096 0 0
fconfig USBBoot_nand.cfg 0
nprog 0 u-boot-nand.bin 0 0 -n

После успешного завершения прошивки подключаем вогоплеер к COM-порту, запускаем терминальную программу (лучше Hyper Terminal, настройки порта – 57600 бод, 8 бит данных, 1 стоповый бит, без проверки четности и управления потоком) и “перезагружаем” его передергиванием питания.

Если все настроено правильно, то в терминал вывалится вот такая “простыня” текста:

NAND Secondary Program Loader
Starting U-Boot ...
U-Boot 1.1.6 (Feb 1 2011 - 22:13:18)
Board: Ingenic VOLANS (CPU Speed 336 MHz)
DRAM: 32 MB
Flash: 0 kB
NAND:1024 MiB
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x400000, size 0x300000
3145728 bytes read: OK
## Booting image at 80600000 ...
Bad Magic Number
VOLANS #

Все заканчивается приглашением к вводу. U-Boot – очень мощная программа, фактически – небольшая однозадачная операционная система, типа DOS или CP/M. Список команд можно посмотреть, набрав help, он достаточно велик, но сейчас нас больше всего интересует запуск “самописного” софта. При компиляции U-Boot автоматически “собрался” небольшой пример. Для его загрузки набираем команду loads, а затем загружаем текстовый файл hello_world.srec из поддиректории examples, находящейся там, где мы собирали U-Boot.

VOLANS # loads
## Ready for S-Record download ...
S705802000005A012080B00120804D03208080012080E6
## First Load Addr = 0x80200000
## Last Load Addr = 0x802003A7
## Total Size = 0x000003A8 = 936 Bytes
## Start Addr = 0x80200000
VOLANS #

Пользователи PuTTY, видимо, оказались в пролете. Самописный софт для U-Boot может использовать небольшую часть стандартной библиотеки C, реализованную в U-Boot. Этого хватает, например, для вполне осмысленного Hello, World. Запускаем его командой go 80200000.

VOLANS # go 80200000 Hello Ingenic World from shura@luberetsky.ru
## Starting application at 0x80200000 ...
Example expects ABI version 3
Actual U-Boot ABI version 3
Hello World
argc = 6
argv[0] = "80200000"
argv[1] = "Hello"
argv[2] = "Ingenic"
argv[3] = "World"
argv[4] = "from"
argv[5] = "shura@luberetsky.ru"
argv[6] = ""
Hit any key to exit ...
## Application terminated, rc = 0x0
VOLANS #

Думаю, теперь не составит труда написать что-то вроде 99 bottles of beer, ну а я более плотно займусь Minix-ом. Во всяком случае, теперь у девайса есть boot monitor в лице U-Boot’а и нормальная консоль в виде Hyper Terminal :) Что еще надо для запуска Unix-образной операционки?

toolchain для Ingenic’овских плат

Я уже успел рассказать людям, что занимаюсь портированием Minix 3 на Ingenic’овские процессоры, поэтому мне не удастся сделать вид, что я “пальцы крестиком держал” и ничего толком не делал. Надеюсь, что читающие этот пост не по диагонали уже прочитали всю китайскую документацию, и им не надо объяснять, где искать файл mips_toolchain_guide_EN.pdf. Больших откровений не будет, пишу я скорее для себя, чтобы не забыть последовательность правильных действий.

Итак, первоочередная задача – получить работающий кросс-компилятор, способный собрать исполняемые файлы для “китайского” MIPS. Задача осложнена тем, что занимается этим закоренелый виндузятник. Впрочем, для закоренелых виндузятников имеется такая замечательная вещь, как Cygwin.

Итак, начинаем с установки Cygwin-а. Это аналогичный MSYS “эмулятор” POSIX-совместимой системы, чем-то приглянувшийся китайцам – все утилиты из “комплекта разработчика” для Ingenic’а скомпилированы для Cygwin. Установка довольно проста, внесу от себя лишь одно дополнение – сразу же поставьте пакеты make и gcc. Они понадобятся при компиляции U-Boot.

Второй шаг – установка кросс-компилятора. Берем файл mipsel-gcc4.1-cygwin-nopic.tar.bz2 и распаковываем его в какую-нибудь директорию. Дальше добавляем ее в PATH:

export PATH='/some/path/mipseltools-v-1-2-3/bin':$PATH

После этого можно проверить его работоспособность “китайским” методом, с помощью компиляции helloworld.c – и наверное, даже нужно, подробнее читайте в mips_toolchain_guide_EN.pdf, а мы сделаем один шаг дальше – попробуем собрать U-Boot. Последняя его версия с правками от китайцев и “наших” разработчиков лежит в файловом архиве VoGeeky.

Я буду собирать версию всей этой гадости для pavo, поэтому выполняем команды

make pavo_nand_config
make

По какой-то мне пока непонятной причине некорректно работает утилита, создающая заголовочный файл с картинкой. make вываливается с ошибкой, если после нее попытаться продолжить, то ошибка возникнет в файле lcd.c. У меня не было желания разбираться с глюком, поэтому я пока обошел его так – добавил в конец файла include/bmplogo.h забытый #endif (и убрал оттуда сообщение об ошибке), а в файле common/lcd.c закомментировал все тело функции bitmap_plot().

После всех этих извращений U-Boot успешно собрался, а файл uboot-nand.bin прекрасно запустился в эмуляторе Pavo (только вот логотип не показал, что и логично).

Итак, я получил работающий toolchain, который может собирать софт для “голого” железа. Удивительно, но особых “подводных камней” не возникло. Дальше я немного поизвращаюсь на C для “голого” железа, без ОС, а затем вплотную займусь Minix’ом. Прежде всего придется продумать его загрузку. Я не хочу писать “вторичный загрузчик”, работающий после U-Boot, но не хочу и переделывать “загрузочный образ” Minix. Наверное, это можно решить с помощью скрипта для U-Boot. Ну и bmp_logo.c подправлю, куда без него.

Про важность звукового сопровождения

Вот и я стал счастливым обладателем вкладыша от журнала Vogue с видеорекламой, за что безмерная благодарность отправляется в адрес тов. [info]dlinyj. Первым делом вкладыш был выдран из журнала, а затем и полностью разорван – ИМХО, гораздо удобнее “работать” с ним в таком виде.

На пустующие места вдоль края платы были запаяны более-менее подходящие кнопки, вместо датчика открывания страницы впаял перемычку. Включение-выключение девайса осуществляется кнопкой с подписью Power – крайней справа. Плату и аккумулятор прикрутил к дисплею синей изолентой. Для полного счастья надо заменить динамик на разъем для наушников. На штатное место в плате подходят разъемы из ассортимента “Бурого медведя”, но ехать за ними до Нового Года неохота, а после – это уже очень отдаленное будущее, учитывая, что вся страна будет пить аж десять дней. В общем, получилось некое подобие видеоплеера, которым это чудо и было до попадания в лапы Americhip.

“Порадовало” то, что при включении плеера явно слышны наводки на звуковой тракт от цифровой части. Правда, звуки немного напоминают “шуршание” жесткого диска и вызывают ностальгические воспоминания про мой первый писюк (Pentium 120 MHz, 16 Mb RAM, 800 Mb HDD). За неимением версии Windows 95 для MIPS буду портировать туда Minix, а потом – Equinox Desktop Environment :)

PS Плата у меня Ылитного синего цвета :)

Большой превед от Intel

Теперь замечательная функция RadioKill доступна не только Пентагону, ЦРУ и Моссаду, а каждому желающему. Причем информация эта поступила не от злобных ксакепов, и не от спецслужб России, Ирана или Китая, а от самого руководителя отдела продаж Intel. Читаем, фтыкаем (via [info]vitus_wagner):

http://www.techspot.com/news/41643-intels-sandy-bridge-processors-have-a-remote-kill-switch.html

Кто гарантирует, что Intel не “раскрыл” уже давно присутствующую в процессорах функцию, а спроектировал непонятную фичу “с нуля”? Теперь истинный параноик, помимо разведения свиней в зиндане, просто-таки должен собрать процессор из TTL-микросхем, а в качестве операционки поставить собственноручно переписанный Minix.

Как я разобрался с эмулятором

В общем, в этот четверг я разобрался, почему не работал эмулятор qemu-JZ. К сожалению, мне так и не удалось запустить на нем Linux. U-Boot и ядро загружаются, но не удается получить работоспособную файловую систему. На некоторых из них с ошибкой валится стартовая проверка целостности флешки (это относится к ФС с сайта Ingenic), в сборках konst.cranky странным образом пропадают некоторые файлы (причем необходимые для запуска системы – в одном случае нет /bin/sh, в другом – /dev/console). Кроме того, удалось заставить китайскую утилиту для создания образа флешки работать в MinGW (а также написать свою, практически аналогичную) – надо явным образом добавить ко всем вызовам open() флаг O_BINARY.

Выложу, что ли, подправленные архивы с исходниками, желающие могут поковыряться. Qemu надо собирать, как описано на форуме qemu:

1. Установить MSYS, msysDTK, MinGW.
2. В MinGW установить или скомпилировать из исходников библиотеки directx-devel, SDL, zlib
3. Затем распаковать архив с qemu-JZ, выполнить ./configure --static --target-list=mipsel-softmmu, затем make.

После этого забираем из директории mipsel-softmmu готовый файл qemu-mipsel-softmmu.exe.

С поправленным jz-tools все еще проще. Распаковываем и собираем make-ом.

Файлы лежат у меня:

http://shura.luberetsky.ru/tools/qemu-JZ.rar
http://shura.luberetsky.ru/tools/jz_tools.rar

Кто хочет “поковырять” – берите. Подозреваю, что в qemu-JZ не совсем адекватно эмулируется флешка, оттого и глюки ядра Linux при ее проверке.

Кстати, насчет глюков на уровне ядра операционки. Если в любой нормальной ОС вылет драйвера файловой системы – это “тушите свет, сливайте воду” и полный kernel panic (в общем, что я и наблюдал), то в кошерном Minix паникеров расстреливает и заменяет свежими заградотряд, почему-то названный Reincarnation Server. Вчера “добился” сбоя драйвера VFS (Virtual File System) в Minix 3.1.8 – представьте себе, это совершенно незаметно, заглючивший драйвер моментально перезапустился. Все-таки микроядерность имеет свои преимущества.

Кроме того, в документации на процессорное ядро MIPS32 4Kc (оно совместимо с XBurst, но китайцы этого не афишируют, чтобы не платить лицензионные отчисления) написано о том, что предусмотрен специальный механизм, позволяющий не выгружать из MMU (Memory Management Unit) страницы, соответствующие ядру. Это позволяет избежать “дорогостоящего” переключения контекста, которое в более традиционных системах возникает при каждом вызове ядра и возврате в “пользовательский” процесс (а они у микроядер происходят часто). Надо поиграться, а то и сравнить производительность в обоих случаях.

Про qemu под Minix

Кстати, нашел среди миниксовских пакетов qemu версии 0.12.2. Может, попробовать собрать под ним qemu-JZ? В принципе, можно даже попытаться перенести все портирование миникса на JZ47xx в сам миникс. Где-то у меня валялся “ненужный” винчестер, так что можно и попробовать.

Извращение, конечно, но нынешним линуксом, по слухам, пользоваться реально скучно, примерно как 98 виндой.

Бинарные пакеты от старых версий в Minix 3.1.8

Поставил в виртуалке Minix 3.1.8, ужаснулся тому, что вместо старого доброго packman теперь используется утилита pkgin. Естественно, поменяли шило на мыло, но при этом из списка доступных пакетов пропали многие полезные вещи. Как же теперь поставить замечательный оконный менеджер ede (применяется, например, в ОС МСВС)?

Оказывается, все эти дистрибутивы выложены на “русском” ftp-сервере ftp://ftp.minix3.ru. В состав дистрибутива входят программы ftp и tar, остальное – дело техники. “Пакет” в Minix представляет собой обычный архив, который надо распаковать поверх корневой файловой системы.

Хочу извращений

Так и не нашел я в окрестных лабазах пресловутого номера Vogue, думаю, что в ближайшее время аналогичная реклама вряд ли где появится (хотя не исключаю рекламу водки “Погань” в журнале “Ксакеп”). А вот всякой документации на процессоры фирмы Ingenic почитал порядочно.

Довольно интересная штука за авторством этой фирмы – демо-плата PAVO на процессоре Jz4740.

ingenicdemo

Самое замечательное – то, что эта демо-плата эмулируется в QEMU, точнее, в доработанном китайцами QEMU. Их страничка так и называется – JZ Hacking. Там можно скачать работающий (ладно, компилящийся) QEMU с доработками, прошивку для девайса, а также несколько утилит для создания “правильного” образа флешки из файлов *.bin.

mipsel-qemu

Кстати, никто не “подкидывал” эмулятору образ флешки, вытащенный из Vogue? Или наоборот – никто не заливал в Vogue прошивку от PAVO? Впрочем, я не про это. Лично мне кажется, что в портировании Линукса на очередную китайскую плату нет какого-то “драйва”. Китайцы все равно это уже сделали, и не хуже многих. Потом, мне Линукс не нравится из религиозных соображений :)

А вот поковырять платку (или эмулятор) в плане запуска на ней Minix 3 – довольно забавное, с моей точки зрения, занятие. Насколько я понимаю, разные процессоры Jz47xx отличаются в основном набором периферии – которую можно вынести в драйверы. Процессорное ядро там одинаковое, причем совместимое с MIPS.

К сожалению, Ingenic-овский FTP огородили от любителей халявы, и теперь он требует пароль :( Придется еще и заниматься reverse engineering-ом по исходникам QEMU.

Скажете, извращение? А вот лично мне интересно. Если не будет возникать особенных сложностей – буду писать в своем уютненьком под тегом “миникс“. Думаю, что два-три часа в неделю на извращения я найду, а по опыту вот этого мужичка – этого вполне достаточно для “любительского” проекта.

Безотносительно морских свинок

Женщина-программист, устанавливающая извращенный говнософт в одиночку – это страшно. А вдвойне страшно – когда приходится еще и “лечить геморрой по телефону”, находясь в разных часовых поясах. Из разговора о том, что IIS бастует и выдает ошибку:

Ой, там IIS выдал ошибку, я не запомнила, там что-то было про Information Services!…

Все-таки в том, что PHP и Apache на порядок проще соответственно ASP.NET и IIS есть своя сермяжная правда. Хотя даже наличие такой замечательной вещи, как XAMPP иногда не помогает. А как вы считаете, должен ли PHP-программист знать о том, как настраивается Apache через httpd.conf?

PS Плюну на все и уйду в монастырь открою хостинг с Apache, PHP и MySQL на миниксе, благо они там есть. Специально для конченых маньяков.

UPD В свете последних известий надо будет еще и запускать миникс на вкладыше от журнала Vogue.

Про операционку MINIX

Воинствующие линуксоиды любят упирать на то, что благодаря принципу Open Source, они могут свободно изучать работу операционных систем на примере своего любимого Linux. Интересно, что может почерпнуть обычный среднестатистический программист из (примерно) 5 миллионов строк кода, из которых состоит так называемое “ядро” системы? Наверное, используя Linux, можно научиться только… использовать этот самый Linux, что само по себе тоже неплохо и даже иногда полезно, но имеет ровно то же отношение к “работе операционных систем”, что и кнопконажимательство в Windows.

Что бы там ни говорили фанаты Free Software Foundation, сегодняшний Linux – это абсолютно коммерческий проект с совершенно ясными целями, в которые совершенно не входит доступность ОС для изучения всеми желающими, а если и входит – то на предпоследнем месте (на последнем – увеличение капитала Билла Гейтса, естественно). Если бы я был Биллом Гейтсом и хотел бы окончательно задушить Linux – я бы начал бесплатно раздавать школьникам и студентам исходники, к примеру, Windows 2000 или XP (по своему “развитию” современный Linux примерно соответствует NT 5.0 или 5.1), естественно, с комплектом кривых драйверов :)

ИМХО, без нормального руководства изучить функционирование довольно сложной операционной системы “на самом нижнем уровне” практически невозможно. Так вот, проблема в том, что такое руководство для современного Linux написать не получится – с ним получилось то же самое, что с Unix в 90-е – он стал слишком сложен.

Кроме того, не будем забывать и о прикладных программах. Конечно, патчить KDE 2 под FreeBSD – тоже полезное умение, но ценное только для закоренелых “красноглазиков”. А ведь немалая часть “изучения” Linux или современных *BSD – это преодоление таких вот трудностей.

В общем, сойдемся на том, что так называемое “изучение функционирования ОС” на примере Linux невозможно. Многим оно, естественно, не нужно, но вот лично у меня нашлось некоторое количество условно свободного времени, которое захотелось потратить на чтение приличных книжек по так называемому “Computer Science” (от слов “информатика и вычислительная техника” веет страшными временами, когда Лаврентий Палыч Берия рулил разработкой первых советских ЭВМ :)). Когда-то давно я купил книжку Таненбаума, но так и не сподобился прочитать ее. А вот на днях зашел в википузию и узнал, что Таненбаум все еще жив, здоров и мелко гадит своим студентам, заставляя их отлаживать третью версию своей “передовой” (по мнению Таненбаума) операционки Minix 3, и даже подробно описал ее в книге “Операционные системы: разработка и реализация” (ядро Minix – это около 4 тысяч строк на C, плюс некоторое количество драйверов и т. п. – итого около 20 тысяч строк, вполне обозримо при наличии желания).

Чем интересен Minix, кроме своей “обозримости”? Таненбаум пытается реализовать в нем принцип микроядерной архитектуры, когда драйверы устройств представляют собой выполняемые в user-mode программы. Думаю, ни для кого не секрет, что синие экраны в Windows или kernel panic в Linux в подавляющем большинстве случаев вызваны ошибками в драйверах. Если драйвер работает в ring 0 (то есть без аппаратных блокировок некоторых губительных для ядра ОС действий), то ошибка в нем практически всегда является причиной сбоя всей системы. Продвигаемая Таненбаумом идея состоит в том, чтобы все драйвера устройств выполнялись с минимальными для их работы “правами”, не имея возможности обрушить всю систему разом.

Кстати, в Windows реализовано некоторое подобие “микроядра” (хотя применить слово “микро” к ядру Windows сложновато :)). Особенно хочется обратить внимание на Windows 7. Не буду говорить о том, что часть драйверов (minidriver в терминологии Microsoft) работает в пользовательском режиме во всех версиях Windows, а обращу внимание на довольно серьезное отличие “семерки” от предыдущих версий – Microsoft наконец вынес из пространства ядра видеодрайвер, теперь при его сбое просто погаснет экран, а затем картинка восстановится с уведомлением в правом нижнем углу – “Видеодрайвер был перезапущен, приносим свои извинения, тушите свет, сливайте воду”. UPD: Тут я набрехал, оказывается, видеодрайвер выполняется в user mode уже в Vista.

В общем, я отвлекся, скажу лишь, почему меня потянуло на операционные системы. Еще лет пять назад я извращался в эмуляторе Unreal Speccy, писал всякую чушь на ассемблере Z80. Например, наколбасил некое подобие “менеджера памяти”. Если кто-то не знает, ZX Spectrum – это семейство компьютеров на восьмиразрядном процессоре Z80. Этот процессор представляет собой клон Intel 8080 с некоторыми расширениями и был очень популярен в 80-е. Как тогда полагалось, Z80 имел 16-разрядную шину памяти и мог адресовать 64 кБ памяти (из 4 страниц по 16 кБ). Существовало два врианта ZX Spectrum. В первом младшие 16 кБ занимала “прошивка”, старшие представляли собой 48 килобайт оперативной памяти, довольно много для начала 80-х. В более поздних вариантах памяти было аж 128 килобайт, доступ к ним был организован довольно нетривиальным образом. Первые 16 килобайт занимала прошивка, затем шли 0 и 1 страницы памяти, в последние 16 килобайт можно было “вставить” любую из остальных страниц. В СССР и позднее – незалежной Рохляндии наши башковитые инженеры разработали несколько вариантов Spectrum-совместимых ПК, но на этом не остановились, а пошли дальше. Примерно таких же образом, через “окно” в памяти, разработчики клонов организовали доступ сначала к 256 кБ, а затем и к 1, 2 и 4 МБ ОЗУ. Существовало несколько “стандартов”, отличавшихся временем переключения страниц и способом доступа к ним. В общем, в порядке изучения ассемблера Z80, я реализовал “подпрограмму” перевода некоего трехбайтового “указателя” в двухбайтовый, загружающую в “окно” нужную страницу. Работала она на всех вариантах подключения дополнительной памяти, которые были реализованы в эмуляторе. В принципе, подобное чудо программирования можно назвать гордым словом “менеджер памяти” :) Было и несколько других “проектов”, уже на микроконтролерах, где приходилось как-то решать проблему с некоторым подобием “многозадачности” (обычно все сводилось к самой примитивной кооперативной многозадачности), так что тема эта мне немного знакома, хоть и в “игрушечном” варианте.

В общем, по жизни мне иногда приходилось сталкиваться с необходимостью реализации чего-то похожего на операционную систему – от переключения между несколькими задачами в микроконтролере PIC до пары более серьезных “изобретений велосипедов” на AVR. Программирование для микроконтролеров, конечно, довольно сильно отличается от программирования для “полноценных” компьютеров, но те же старшие AVR уже не уступают по параметрам тому же Spectrum, а в ближайшие пару лет станут доступны МК, на которых еще нельзя запустить Linux, но уже хочется какого-то подобия операционки. Вот так, окольными путями, меня и занесло в сторону Minix.

Что могу сказать? По удобству настройки и количеству софта Minix далеко позади любой другой современной ОС. Но “пощупать” его я решил не из-за этого, а из-за наличия неплохого описания его работы на самом “нижнем” уровне. В принципе, мне более-менее понравилась документация и я решил поставить операционку на завалявшийся у меня полуубитый винчестер (как-то не хочется мне связываться с мультизагрузчиками, так что пусть стоит совсем отдельно). В ходе установки оказалось, что по дефолту в операционке нет драйвера для моей сетевой карты (на самом деле есть, только в нем не прописаны нужные PCI Vendor и Device ID), поэтому потом я запустил сие чудо под Virtual PC.

Даже конченного виндузятника вроде меня не испугала перспектива оказаться наедине с консолью и компилятором C. Я писал программки в подобной среде, и не особо жаловался – даже находил некоторое извращенское удовольствие. Вывод ясен – дайте две!

Скриншот для порядку

Скриншот для порядку

Естественно, не все в Minix так плохо. Портировано довольно много юниксового софта, в том числе X11R6, несколько оконных менеджеров, gcc, браузеры links и lynx, десяток текстовых редакторов – короче говоря, половина пакетов в packman прекрасно заменяется другой половиной. Это очень юниксвейно – у пользователя всегда должен быть выбор, особенно – среди нескольких мало отличающихся текстовых редакторов :)

Конечно, времени “полапать” Minix со всех сторон у меня пока не было, но с запуском X и сетевого драйвера в виртуальной машине я разобрался. Компилятор компилит, а что еще нужно в юниксообразной ОС для счастья? Краткое резюме такое: Minix можно использовать для обучения студентов программированию (особенно, если настроить в компиляторе опцию “Treat warnings as errors”, кто помнит – смахнет скупую слезу), или, что практически эквивалентно, для удовлетворения собственного любопытства.

Любимый аргумент линуксоидов в холиваре “Windows vs Linux” – “Я свою тещу пересадил на Linux, сидит не нарадуется”. Думаю, с пересаживанием тещ на Minix придется подождать, но кое-какой набор софта там есть. Например, я попробовал:

- текстовый редактор elle – такой юниксвейный блокнот (elle looking like emacs), подсказка – для сохранения файла нажмите Ctrl+W (Write), для выхода – Ctrl+X два раза, потом Y.
- teTeX – обычный такой TeX, ничем не примечательный, прикручиваются русские шрифты, можно жить
- ACK – Amsterdam Compiler Kit – укуренный компилятор C, вроде как ANSI C-совместимый
- links – браузер, недалеко ушедший от Opera Mini или прочих “мобильных” браузеров, некий гибрид текстового и нормального браузеров. Шрифты говно.

В принципе, можно поставить сие чудо в компьютерном классе в каком-нибудь техническом ВУЗе, запереть там студентов и ждать самозарождения всяких там линуксов. Можно даже положить на полочку какие-нибудь полезные книжки (пару руководств по ANSI C, плюс талмуд Таненбаума). Система вполне “ковырябельна”, баги есть, что еще нужно для счастья программиста-мазохиста?

PS Кстати, как известно, я ненавижу школьников и преподавателей информатики. Так что надо задуматься по поводу “школьного миникса”, срубить кучу денег с гой-сударства и лично депутата Алксниса, а потом окончательно поработить мир :) Вот вам и про садистское применение Minix.

PPS Кстати, вроде как есть несколько проектов по портированию Minix на архитектуру ARM. Вот тогда заживем! :)