Виноват "ARM system-on-chip architecture" Исходники для "ARM System Developers Guide"
Попутно вопрос - а почему у вас интерес к этой "зверушке", а не к uOS, например? Или портировать Minix? А то вот сам хотел учить линукс, но что-то теперь задумался - все ли так гладко с его использованием для атмеловских чипов (почему к каждой версии ядра патчи выпускают?) и не стоит ли для начала попытаться освоить освоить что-то попроще (freertos, tnkernel и т.д.)?
Не знаю - мне она понравилась своей продуманностью, чистотой кода, хорошей документированностью поддержкой mmu, гибридное ядро - не модульная куча мала как linux или uos и вообще для понимания работы ОС мне кажется она просто идеальна - там достаточно много всего с минимумом кода. linux - хорошая ос - стоит с ней ознакомиться, просто я с ней уже давно знаком, а на армах так имхо ему вообще конкурентов сейчас нет в плане наличия и разнообразия готового софта.
Частично решил проблему с mmu - нашел причину, ядро и модули загружаются но пока спотыкается на загрузке юзерспейсных задач, копаю дальше... Как оказалось дело было в кэше - в прексе на даннный момент я не нашел как сделать красиво,чтобы память отводимая под таблицы страниц не кэшировалась или хотя бы использовалась политика writethrough, после изменения таблиц подается команда на инвалидацию tlb и данные просто терялись. Пока решил проблему радикально - установил общую политику кэша данных процессора writethrough. Что интересно - эмулятор спокойно глотаал такой код и ему плевать на политики кэшей :) Так что эмуляторы далеки от реального железа...
я пару дней поковырял ММУ и бросил, надо многое с ноля переписывать, не понятно как оно на интеграторе работает. сделал без ММУ. для стандалоне задач - вполне. один хрен - игрушка, пока сеть не прикрутят.
У меня стойкое ощущение что у автора оно никогда там и не работало :) По крайней мере с таблицами страниц там полный бардак. Я сейчас переделал на маленькие страницы 1024 байт и fine pages таблицы второго уровня, кэш writethrough - вроде должно все работать но при загрузке заданий, это когда новое значение pgd в mmu перезагружается работает не так как хотелось :) Пока не разобрался что там происходит. Думаю сам механизм работы с виртуальной памятью нормально работает хотя бы на х86 а проблемы в релизации hal на armах. Мне просто не интересно писать драйверы пока mmu не заработает как надо - собственно lcd и kbd(эмуляцию ps/2 на gpio) можно очень быстро соорудить. Осложняется все тем что ос в стадии разработки - в последней версии епонец все поменял в структуре исходников и наработки комьюнити так и остались никому ненужными в git. Думаю у некоторых просто руки опустились после этого.
Наконец я победил mmu :) Система заработала на реальном процессоре с включенным mmu, правда авторский вариант пришлось слегка оптимизировать - я опять вернулся на схему coarse page table + small page size (оказывается armv6 уже не поддерживает tiny page size и для переносимости на будущие процессоры не рекомендуется использовать такой размер страниц), изменил инициализацию mmu, перенес таблицу векторов исключений в верхнюю память, до нахождения красивого метода отменил кэширование на уровне всех страниц.
Если кому-то нтересно :) вот тут патчи.
Базовый - добавляет поддержку at91sam9 в prex http://sasamy.narod.ru/armwork/at91_base.patch
То что каcается поддержки mmu - накладывается после базового http://sasamy.narod.ru/armwork/at91_mmu.patch
Консоль на usart2, чтобы что-то видеть нужно переключить плату на usart2 (переставить перемычкус dbgu на usart2) + в uboot нужно в конфиге задать консоль на usart2.
15.01.2010 22:48
16.01.2010 19:43
