arm toolchain

Не так то просто собрать свой тулчейн.

Поскольку стандартная прошивка LPC писалась под старый uclinux, то мне просто необходимо было иметь binutils с elf2flt, потому что там основной формат flat. К тому же мне абсолютно не нужен был glibc.

Долго я с этим возился, и как вижу - я не одинок в этом...

чего мне пока с последними версиями gcc проделать на удалось - под ARM собираться не хочет, binutils собираются, bootstrap compiler тоже, а сборка libc - сваливается... или это сборка полноценного компилера? не помню уже... после десятка безуспешных попыток я это дело отложил на неопределенное время.

Источник

Начнем с того, что стандартные средства gentoo (crossdev) хоть и предполагают, но не могут собрать toolchain с uClibc. А поддержка elf2flt видимо когда-то и была, но ныне включается только ковырянием в ебилдах.

Стандартные средства uClinux имеют волосатую дату 14 марта 2003 и включают в себя старый binutils который не в состоянии собрать нынешнее ядро. С неофициальным тулчейном ситуация не намного лучше, ибо он базируется на gcc-3.4.0, в то время как <gcc-3.4.1 имел баг с компиляцией на arm, что также дает полную неюзабельность данных пакетов. А еще я убил бы того, кто придумал закатывать архивы в .sh! Моя система имеет локаль по умолчанию - UTF8. Похоже, что именно это не дает скрипту нормально отрабатывать ибо UTF8 пребразование превращает архив непонятно во что. Пришлось выцеплять архив из .sh файла при помощи dd, после чего их стало возможным раскрутить, но всеравно бестолку.

Есть предположение, что разработчики uClinux забросили эти инструменты в пользу buildroot, который, в отличи от OpenEmbedded, заточен на uClinux. И если повезет, то можно найти снапшот (стабильного релиза так и не нашел), который, после небольшой доработки напильником сможет собрать корректный тулчейн. Так я и поступил, ибо то, что пытаюсь собрать я сам, упорно не хочет работать ругаясь то на отсутствие либ, то на некорректность бинарей.

Вообще я наверное что-то не понимаю, но мне кажется что с кросскомпиляцией GNU'шники что-то намудрили.

PS: А еще почему-то когда я делаю выравнивание вправо у меня сразу меняется межстрочный интервал. глюка какая-то.

mencoder bug???

С сентября меня мучает одна проблема. Мой mencoder почему-то разучился корректно кодировать видео в два прохода. Что я только не делал, пересобирал mplayer с различными USE-флагами (пытался отключать оптимизации всякие), различные опции кодирования менял. Однопроходное кодирование работает корректно, а после второго прохода видео корректно отображает кажется только сам mplayer.

Многочисленные дальнейшие эксперименты показали что кодирование через ffmpeg дает точно такой-же некорректный результат. Вместо 23 минут видео почти все плейеры показывают около 4 часов. Формат звуковой дорожки абсолютно не при чем, менял форматы, но даже один видеопоток отображается некорректно. Так же пытался менять и контейнер (вдруг это проблема avi?), но mpeg точно так же врет.

В порыве отчаяния я пересобрал все до mplayer (emerge -e mplayer), но и это абсолютно ничего не дало. Я что-то не понимаю, неужели никто под gentoo не кодирует видео? Не кодирует в два прохода? Или эта проблема только у меня (руки?). Ведь не может быть такого чтобы за три месяца никто не озадачился проблемой корректности двухпроходного кодирования, ежели она всетаки присутствует.

Где я только не искал отгадку, но пока ее не обнаруживаю. Так и сижу, как дурак, без mencoder'а.

Cryptoloop in action...

Что касается LPC2468 (ранее упоминавшегося ARM), то мне удалось отыскать hsc0 патч для ядра 2.6.11.8, что позволило отделить зерна от плевел... То есть отделить изменения касающиеся непосредствено плат LPC от изменений hsc0. Теперь я могу наверное с минимумом напильника наложить архитектуру LPC на более свежее ядро... Но это будет уже в следующем году.

А пока вожусь с шифрованием. Реализовал шифрование по ГОСТ 28147-89 для ядра, там оказалось все достаточно грамотно сделано в этом плане. Режимы работы блочных шифров (правда только CBC и ECB) ядро реализует универсально. От модуля шифрования лишь требуется предоставить две функции по шифрованию и расшифрованию блока. Мне даже удалось без проблем заставить работать со всем этим cryptoloop девайс. Шифрует эта железяка конечно очень медленно... ни один алгоритм не разогнался до 100kib/s, будем искать железку помощнее (пока положили глаз на Intel PXA 806Mhz).

Но не смотря на все трудности основной режим проекта - проходное шифрование флешек уже работает. То есть флешка втыкается к LPC2468 в хостовый разъем, а сама LPC2468 втыкается в комп как девайс. И комп видит флешку, как живую (только медленную), при этом если флешку просто воткнуть в комп, то видно, что над ней кто-то жестоко поиздевался, сплошной urandom.

Не знаю как они собираются сделать проходное шифрование IDE, SATA. Но задачка будет интересная.

Что первичнее - cтраницы или сегменты?

Ну лаконичность .S длилась недолго... Сейчас в нем начинает прибавляться функций, переходники для исключений, большинство реализуется через единственный макрос. Этот макрос подойдет так же для переходников прерываний, но не подойдет для сервисов. С ними вообще сложнее, для каждого системного вызова понадобиться свой переходник.

И еще никак не удается исбавится от зависимостей. В переходниках необходимо явно использовать селектор данных ядра, но поскольку сишный дефайн там не доступен - приходится мучаться. Либо определить константу в .S (она превратиться в метку sic! да и одна константа описанная дважды - плохо), либо писать явное значение (хардкод еще хуже чем сдублированая константа), или можно заложиться на взаимозависимость cs и селектора кода данных (ds = cs + 8) (не слишком ли хитро все запутано?). Наиболее предпочтительным выглядит первый вариант, если бы он не превращался в метку, а так второй вариант с комментарием наверное не слишком плохо (пока один раз, но одним разом не обойдется, придется дефайнить).

В этом ядре я пошел на небольшую хитрость... Архитектура IA32 устроена так, что сегментная защита реализуется на уровне линейной памяти (то есть страничное преобразование - это более низменный механизм). Это, по логике вещей, требует инициализировать сперва страничное преобразование, а уж потом включать сегменты и таблицы прерываний. Но таблица прерываний, а в частности исключения, весьма полезная штука. Чем раньше они будут включены, тем лучше. Поэтому я сперва проинициализировал GDT и IDT. Но поскольку адреса таблиц при переходе в страничный режим не изменятся, то и значения это не имеет.

Это в старое ядро я мог по началу мапить куда угодно... Это было конечно очень круто, но по большому счету бесполезно. Гораздо проще оказалось мапить ядро по тем же адресам, по которым оно загружено, что и было сделано еще в прошлой версии ядра. Но порядок инициализации страницы, сегменты сохранился... А теперь, когда я исходно не собираюсь менять адреса, то могу позволить себе такие вот маленькие хитрости.

GNU as

Почему-то последнее время у меня сформировалось ошибочное мнение, что препроцессор as аналогичен сишному, что позволяет пользоваться одними заголовками на всех, и вообще очень удобно... Но как же я ошибался...

До сих пор я не особо писал на as. Так, инлайны иногда... но вот в последнем ядре решил переписать минимальную ассемблерную часть на as, ибо она настолько минимальна, что нет смысла ради нее держать еще один дополнительный инструмент вроде nasm/yasm.

Но как выяснилось as препроцессор нисколько не совместим с си. А применение сишного препроцессора к .s файлам может привести к загадочным результатам... Например ключевое слово .arch i386 после си препроцессинга превращается в... .arch 1 :(. А константа, описанная в ассемблерной нотации автоматически становится абсолютной меткой. Интель синтакс вообще не понятно как использовать.

Но есть и положительные моменты... Например все неописанные имена автоматически становятся внешними.

Короче после некоторых экспериментов мультибут заголовок был перенесен в сишную часть, а в ассемблерной части остались лишь минимальные функции, которые пока не нуждаются в каких либо константах... зато лаконичности прибавилось. Ассемблерная часть получилась весьма прозрачная.