варианты ОСей для армов, что лучше? Опции

[Playnet]

Собираем плату на арме и появился вопрос, что лучше использовать как ось?
Есть поддержка у:
Gentoo (на сайте про это почти ничего нет, последние обновления аж в 2005 году)

Debian
Нашел несколько документов. Все ставят toolchain и qemu.

Эти системы на ядре 2.6 используются чаще всего
по доке http://www.opennet.ru/base/sys/linux_xscale.txt.html , очень древняя дока. Написана в 2004...
патчи к ядру ftp://ftp.arm.linux.org.uk/pub/armlinux/s...l-patches/v2.6/ датированы 2004 годом, где тогда брать более свежие..

FreeBSD
"Поддержка всё ещё минимальна, и покрывает только процессор, шину PCI-X, Ethernet-адаптеры em(4), а также таймер и UART.
Обеспечивается минимальная поддержка процессора StrongARM 1100, однако только в границах тех функций, что эмулирует Simics: CPU, UART и часы."
http://www.freebsd.org/ru/platforms/arm.html
Очень негусто.

NetBSD
Тут вообще непонятно, как собирать. Разве что через qemu.

Какие вообще есть утилиты?

uclinux
Уже изначально версия под микроконтроллеры.. Но каковы особенности и через что собсно надо собирать систему под себя?

А вообще, копаясь в инете, у меня сложилось впечатление, что в 2004-05 годах тема была актуальна, а потом ее просто все забросили.. Одно старье.

[ra9ftm]

Кто-нибудь пробовал испытывать Realtime патчи для linux? Интересует именно четкая работа с переферией, прерываниями (spi, i2c).
Я накладывал, но вываливалось kernel panic при работе с нестандартным драйвером, поэтому пока что отложил

Сообщение отредактировал ra9ftm - Sep 14 2010, 11:39

[DRUID3]

Кто-нибудь пробовал испытывать Realtime патчи для linux? Интересует именно четкая работа с переферией, прерываниями (spi, i2c).
Я накладывал, но вываливалось kernel panic при работе с нестандартным драйвером, поэтому пока что отложил

А чем патчили если не секрет? Теми патчами что превращают ядро в ветку RT? Или чо другое есть? Или имеются в виду модули и либы а-ля posix-1b?

И что не так с SPI? Вот у Вас на компе PCI как на не RT системе работает? ЧОтко? Вся эта возня с RT-OS это "борьба" с планированием - т.е. постановкой процессов на выполнение/завершение. В жизни количество процессов стохастично, а время их запуска асинхронно. В обычных системах постановка большого количества задач на выполнение или обработка одной очень ресурсоемкой может вызвать неопределенную задержку. Система тормозит. А в RT-толко определенную. Система тормозит, но не более чем... . Все это для пользовательской части - обычных программ. В ядре правда несколько другие законы.

Тупой способ сделать RT в линуксе в условиях заводской лаборатории это написать драйвер аппаратного таймера(свой - чтобы точно понимать как он работает - я, например, не редко не могу понять чужой код с лету), а-ля вотчдог. Выбрать максимальный интервал затормаживания. Выбрать критичные к задержкам задачи. Вотчдог шлет сигналы по-ядру. Процесс в пространстве ядра (сделанный как драйвер - будет неивысший приоритет - никакими ренайсами не достижимый) читает структуру runqueue для каждого запущенного процесса. Как только время задержки относительно нашего таймера для критичных задач превышает 0.75 максимального времени, всем второстепенным программам шлется SIGKILL . Как вариант, если есть время листать книжки замазанными машинным маслом руками, длительная борьба с перепланированием - nice/renice или прямо в ядре вызовом соответствующей функции (Бовет-Чезати ст.347).

Но я сделал еще проще - и еще гораздо тупее. . У меня на платке точно известно количество задач. Я попробовал - ничего не тормозит. . Единственная связь - Ethernet. Шлю только UDP пакеты. В ноут по "проводу" 1м длинной . Это даже сервером не назовешь. Если у Вас Web-сервер - то, например, попробуйие отрабатывает ли он 20 соединений при максимальной нагрузке. Если да то поставьте ограничение на 10 - точно отработает. Вот и весь RT-Linux в домашних условиях . Недостаток такого подхода - далеко не 100%-ное выжимание ресурсов из процессора/памяти.