Новости про 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 – за минуту.

Комментарии отключены.