Вот уже больше года «стабильной» версией 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 — за минуту.
![[info]](http://stat.livejournal.com/img/community.gif){kind=small}
![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}