NetBSD на МП системах , кто занимался портированием ?

Интересует процесс портирования NetBSD на микропроцессорные системы и вообще сама организация работы этой оси со специализированной перифирией. Кто сведущ в этих вопросах просьба написать что нибудь полезное или кинуть линки.

www.netbsd.org
только если что они.
а так тебе придется код ядра переписывать =)
а на какие конкретно МПС ты собрался портировать netbsd?

Ээээ... Кхммм... Не уверен, что кто-то вообще этим занимался...

Впрочем, когда-то давно я видел порт FreeBSD на Palm (процы ещё были -- Motorola Dragonball), но, мой Бог, как давно это было!

Если по Linux, то я могу немного помочь (возможно), а NetBSD... Для таких целей... Не смогу, наверное.

Накопал вот такие ссылки:

Linux успешно запущен на Palm Tungsten T3 (фото+рецепт)
Linux успешно запущен на Treo 650 и LifeDrive

Более подробно описываю смысл этого топика.

Я хочу сделать микропроцессорную информационно-измерительную систему под управлением NetBSD. Система будет собирать
информацию с периферийных устройств (в данном случае датчиков) и программно обрабатывать ее. Также будет возможность осуществлять программное управление ИИС. Саму МПС я планирую подобрать такую на которую NetBSD будет портирована без особых затруднений - основными сложностями должны быть написание или модификация уже существующих драйверов (если таковые имеются) для работы с датчиками, ну и возможно организация управления ИИС.

В самом примитивном варианте это может быть например датчик температуры, показания которого обрабатываются, по данным создаются определенные отчеты, графики и тп. В качестве управления такой ИИС можно использовать следующие функции: включение/отключение датчика, задание шкалы (цельсий, фаренгейт) которая нужна и т.п.

вот собственно и все.

проще написать прошивку для МПС и прикрутить к компу через SR232
и пусть у тебя на компе вертится netbsd и пиши драйвер для своего устройства

Цитата karlson @ 20.01.06, 20:57

проще написать прошивку для МПС и прикрутить к компу через SR232
и пусть у тебя на компе вертится netbsd и пиши драйвер для своего устройства

ну да, как вариант я это тоже рассматриваю тока мне тогда уже разницы не будет что у меня крутится будет - хоть NetBSD, хоть линух, хоть винда.

я именно хотел что б сделать полноценный и не зависимый от компа девайс. в этом суть.

так мпс какой будет(тип)?
может там просто netbsd не запустится ввиду аппаратных параметром
типа там памяти данных и памяти программ.

то есть условие такое - только и исключительно NetBSD?

Цитата grustnoe @ 21.01.06, 04:12

то есть условие такое - только и исключительно NetBSD?

да, так как это вполне осуществимо, просьба читать сайт данной операционной системы - повторяю что эта ОС рассчитана на ОЧЕНЬ большое количество платформ.

Цитата karlson @ 20.01.06, 22:01

так мпс какой будет(тип)?
может там просто netbsd не запустится ввиду аппаратных параметром
типа там памяти данных и памяти программ.

я же отметил вверху что мпс будет выбираться так чтоб netbsd на нее встала. понятно дело что на спектрум с 4 килобайтами памяти я ее ставить не собираюсь =)

Цитата

Linux успешно запущен на Palm Tungsten T3 (фото+рецепт)
Linux успешно запущен на Treo 650 и LifeDrive

Не проблема. Запустил на Palm Tungsten W. Поигрался. Интересно. Но смысла особого не вижу. Это так... лирика.

Цитата

Я хочу сделать микропроцессорную информационно-измерительную систему под управлением NetBSD.

Это я уже понял. У меня встречный вопрос -- а зачем воевать с NetBSD? Не лучше ли использовать более простой путь? Я имею ввиду Linux.

Я не просто так задаю сей вопрос -- я просто некоторое представление о "тех. процессе" имею, по этой причине и спаршиваю. Проблема (то, с чем я столкнулся) в том, что вначале всё просто здоровски... Но потом приходит босс и начинает задавать такие вопросы, что понимаешь -- без real-time'а, причём, действительно real-time'а, без дураков, по-честному, нам не обойтись. И тут встаёт вопрос -- а где его, этот самый real-time искать? Вариант с QNX не проходит, т.к. ... Не хочу никого задевать, но на процессорах, отличных от Intel, оно не очень-то живёт.

Единственный выход -- Linux. Но это -- на мой взгляд.

Цитата

повторяю что эта ОС рассчитана на ОЧЕНЬ большое количество платформ.

Кхм... На самом деле, всё несколько проще.

Суть в том, что для переноса (к примеру, Linux) на некий девайс, нам надобно знать следующее:
1. Тип процессора (точно!)
2. Периферия.
3. Размеры EEPROM, RAM, наличие/отсутствие доп. памяти (FLASH/NAND/...).
4. Карту распределения памяти для данного проца.

А, далее, в общих чертах (требуется знать реалии для более-менее точного ответа), всё выглядит так:
1. Готовим tool chain (это GCC, как правило, v. 2.95.x, binutils, coreutils, т.е. всё, потребное для программирования для данного проца). См. список процессоров, поддерживаемых GCC.
Т.е., --target=наш_искомый_проц. К примеру, для ARM, мы получим arm-objres-linux-elf. И прочее и прочее...

Ещё один аспект -- для такого рода девайсов glibc (а какая разница -- Linux, *BSD, etc... если есть gcc, то и glibc где-то рядом обретаются) несколько избыточна. Нам придётся либо использовать dietcc (и делать статическую линковку), либо NewLib, либо uclib... Выбор так же есть... Зависит от того, сколько у нас будет памяти на всём этом оборудовании...

Следовательно, какой софт мы будем делать... См. ниже.

2. Теперь берём ядрышко потребной версии (блин, необходимо смотреть по периферии).
Делаем --arch=наш_проц, конфигурим, и собираем ядро тем набором утиля, который по-имели на шаге первом. Здесь возможно наличие/отсутствие RAM-диска в системе (т.е., будем или нет им пользоваться). Это зависит от версии ядра и здесь надобно крепко по-размыслить -- а оно нам это надо?

Здесь же вопрос -- чего с реал-таймом-то делать, будь он неладен? Если он всё-таки нужен, то нужен патч для ядра, с учётом того, какой проц используем. Как правило, на ARM, к примеру, патчи такого рода уже есть, искать нужно под свою версию ядра (вообще, "версия ядра" определяет какое железо мы будем спокойно использовать, какое -- с напрягом).

И самое весёлое -- если мы всё-таки решили дружить с реал-таймом, то я рекомендовал бы научиться писать "модули ядра" по причине того, что наш софт нам придётся оформлять именно так. Т.е., в реализуемом устройстве, в зависимости от процессора, обработка временных параметров и, как следствие, работа планировщика системы будет весьма и весьма нестандартны (по отношению к "стандартному" дистрибу). Следовательно, для того, чтобы полностью реализовать все эти элементы, наш процесс должен стать "частью системы". Т.е., по большому счёту, именно ядра.

3. Теперь нам потребен bootloader. Т.е., то, что загрузит софт (ядро) в память и передаст управление на ядро. Здесь важна карта распределения адресов в системе. Вопрос, но см. datasheet на целевой процессор. Т.е., в bootloader'е мы указываем где у нас ROM, где RAM, по каким адресам чего подгружать или не подгружать во-все... Зависит от процессора. К примеру, вполне возможно держать ядро в ROM, передавать адреса управления на адреса ROM и проц будет отрабатывать эти команды. Либо загружать код в RAM и отрабатывать его там.

Так что... В общих чертах... И для Linux. Как всё это будет для *BSD... Да, примерно, так же. Т.к. gcc там -- тот же, набор утиля -- то же. Вопрос только в том, как (в деталях) пересобрать ядро и набор утиля для целевого процессора.

Короче, всё как-то так, но, повторяю, это -- просто общее описание "тех. процесса". Детали определяются целевым процессором. К примеру, для ARM, m68k (Motorola Dragonball) -- всё это не проблема. Для других процов -- думать надобно.

Цитата

И самое весёлое -- если мы всё-таки решили дружить с реал-таймом, то я рекомендовал бы научиться писать "модули ядра" по причине того, что наш софт нам придётся оформлять именно так. Т.е., в реализуемом устройстве, в зависимости от процессора, обработка временных параметров и, как следствие, работа планировщика системы будет весьма и весьма нестандартны (по отношению к "стандартному" дистрибу). Следовательно, для того, чтобы полностью реализовать все эти элементы, наш процесс должен стать "частью системы". Т.е., по большому счёту, именно ядра.

Еще веселее -- модуль надо писать не только с учетом специфики ядра Linux, но и выбранной обертки для реалтайма. Ибо, во всяком случае, FSMLabs избрали именно такой подход: поскольку в обычном ядре время отклика гарантировать никто не собрался, то мы пишем сверхъядро со своим шедулером, который это нам гарантирует, а Linux заворачиваем в него как idle-процесс этого ядра. Убивая двух зайцев сразу: Linux как пускалка ПО и поддерживалка целой тучи нереалтаймовых компонент (ибо нефиг изобретать колеса (квадратные и спицами наружу, между прочим)), а обертка и ее модули для, скажем, системы исскуственного дыхания, сэлсэйвера, био... тьфу, ядреного реактора :)

Цитата

Еще веселее -- модуль надо писать не только с учетом специфики ядра Linux, но и выбранной обертки для реалтайма.

Да! Абсолютно точно! Здесь что-то вроде матрицы получается (проц, механизм реализации реалтайма, ядро (версия))... Блин вопросов возникет дофигищи и сразу...

Добавлено 21.01.06, 14:45
Хммм... Ещё интересный проект... http://www.freertos.org/

Цитата the_Shadow @ 21.01.06, 13:51

Вопрос только в том, как (в деталях) пересобрать ядро и набор утиля для целевого процессора.

ядро в бсдшке пересобирается просто, и если требуется другая архитектура - то это там указыватеся при пересборке.

что касается tool chain - то по идее так же все, аналогично подготавливается.

спасибо за развернутые ответы, особенно the_Shadow - теперь я более менее представляю в общем смысле что такое портирование.

Цитата

что касается tool chain - то по идее так же все, аналогично подготавливается.

Да, конечно. GCC, binutils, glibc (dietcc или чего из перечисленного) -- всё одно и то же. Так что, идея сильно разниться не будет. Но вот с релизом вопросы будут.

Цитата

ядро в бсдшке пересобирается просто, и если требуется другая архитектура - то это там указыватеся при пересборке.

Да и с этим то же ясно и понятно... Не вопрос...

У меня другой вопрос -- как там реал-тайм добыть? А он оооооой как бывает нужен.
Если честно, то по-читай "Практическое использование QNX" (или как-то так, синяя такая книга, в мягкой обложке) там Olej писал ещё об одном аспекте, собственно, о продолжении этого же (real-time'а) -- об инверсии приоритетов. Вот тут-то всё самое весёлое и начинается... :(

Проблема в том, что если для desktop-систем оно всё ничего, то для контроллеров -- оно очень даже "чего". Вот все пляски с ударами по бубну из-за этого и начинаются...

Добавлено 21.01.06, 16:56
Ну, ежели чего, то пиши. Чем сможем -- поможем.

Ну человек не раскололся, какие там датчики. Если они обладают хоть вот такусенькой буферизацией (в смысле, если забыл считать в одну наносекунду, то пипец, нет на эту наносекунду показаний), то реалтайм перестает быть критичным вопросом номер раз.

Цитата Ho Im @ 21.01.06, 21:08

Ну человек не раскололся, какие там датчики. Если они обладают хоть вот такусенькой буферизацией (в смысле, если забыл считать в одну наносекунду, то пипец, нет на эту наносекунду показаний), то реалтайм перестает быть критичным вопросом номер раз.

То есть требуется уточнить будет ли датчик снимать показания непрерывно или же "пошагово" с каким либо интервалом между снятием показаний, я так понял ?

Имеется в виду -- критично ли именно гарантированное время отклика? То есть, настанет ли капец, если вдруг ядро решит: "вот тут у меня idle сильно обделен, дам-ка я ему вот этот большой слайс в X микросек", и пока idle ничего не делает, твои датчики успели с регулярным интервалом в X/20 микросек передать всплеск активности того, что ты там мониторишь, причем через X мкс все утихомирилось и твоя система этот всплеск не зафиксировала. Тем временем этого хватило, чтобы, кхм, от направленного взрыва на АЭС снесло небольшой городишко :]=

То есть, в данном случае, та гипотетическая величина в X/20 мкс будет временем отклика, которое система должна гарантировать, хоть бы все зашиблось.

И дело не в малой величине. Реалтайм можно построить на ис-клю-чи-ттельно эст-то-онских скоростях. Например, частота выборки 1 Гц, тогда и требование такое -- чтобы хотя бы раз в секунду система отвлекалась от своей прочей порнографии на считывание данных. Если какой-то левый процесс поимеет возможность заграбастать на себя 1.000 ... \inf секунд, реалтайм не получился. Если система при любой погоде не будет выдавать такие кванты процессам (скажем, жестко зашить 0.1 с, а в системе 6 процессов) -- будет тебе реалтайм.

...А непрерывности как таковой, по-моему, не существует, она если и есть, то исчезает на микросхеме ЦАПа и все упрется на частоту выборки, с которой он будет работать.

Цитата

То есть требуется уточнить будет ли датчик снимать показания непрерывно или же "пошагово" с каким либо интервалом между снятием показаний, я так понял ?

Цитата

...А непрерывности как таковой, по-моему, не существует, она если и есть, то исчезает на микросхеме ЦАПа и все упрется на частоту выборки, с которой он будет работать.

Частота дискретизации, на самом деле. Этим определяется сколько данных за единицу времени (к примеру, 1 сек.) у тебя будет собираться.

Теперь второй вопрос -- как будет работать твой датчик (как он будет организован) -- либо сам накапливать некую часть инфы и, позже сбрасывать на хост, либо сам будет хостом, непрерывно гонящим инфу куда-то для обработки. Это определяется постановкой задачи на разрабатываемую систему ("архитектурой" оной).

Кстати, замечу, что для случая именно термометра -- хост на базе ОС явно избыточен. Т.е., тебе вполне возможно "отбиться" платкой на базе PIC'а (к приемеру, с 18F458 можно работать на частоте внутреннего осциллятора в 40 MHz -- много это или мало?). Причём, на ней же организовать и сбор (буфферизацию информации, если поставить там память) и её первичную обработку (как минимум, реакция на граничные условия -- температура "не больше" и "не меньше" или "резкая дельта в двух соседних выборках"). Т.е., при достижении какой-то пороговой величины, выдавать команду на некий исполнительный механизм (есть возможность работать с I2C, CAN, UART,...).

Ну, как-то всё так.

В принципе, практически одно и то же, просто у тебя термин иностранный, а у меня отечественный :-)

Иное дело, если это хозяйство надо переносным сделать, и чтобы оно внутре какой-либо анализ-подсчет производило -- тогда и процессор хочется поставить, и ОС на него... Хотя обычно достаточно недорогого нотебука на такие случаи.

Цитата

Иное дело, если это хозяйство надо переносным сделать, и чтобы оно внутре какой-либо анализ-подсчет производило -- тогда и процессор хочется поставить, и ОС на него...

Хммм... А не проще ли воспользоваться идеологией Finite-State Mashines (тьфу ты!) "конечных автоматов"?

В принципе, если реакция девайса должна быть простейшая, то... зачем?
А для передачи данных с девайса -- так воооон сколько всяко-разных "шин" по-навояли... Пиши приблуду (хоть под Linux, хоть под NetBSD), ставь на комп, в комп -- шину. А на "шину" -- девайсы простенькие до такой степени, чтобы там глючить было бы нечему... Или как-то так...

Цитата

В принципе, если реакция девайса должна быть простейшая, то... зачем?

Да вспомнился тут совецкий ГСВЧ с "Электроникой-60" внутри. Вопрос, если вычислительные мощности востребованы до такой степени, что мы туда впихиваем ОС, то зачем не делать на рост?

Цитата

Вопрос, если вычислительные мощности востребованы до такой степени, что мы туда впихиваем ОС, то зачем не делать на рост?

Ну, скажем, а зачем платить за выч. мощности больше, нежели нам того потребно?
В принципе, на ARM 7TDMI можно такую платку зачудить. Вот только -- стоит ли оно того? :D:D:D
Если в самом конце мы просто получаем термометр с минимальным функционалом? И не более того.

Цитата

Ну, скажем, а зачем платить за выч. мощности больше, нежели нам того потребно?

Для стендовой системы -- можно переплатить. По ней вычисляем стоимость продакшена.

Иначе упремся в деньги за туеву хучу неудавшихся экспериментальных систем.

Или у разраба уже такая выработанная годами чуйка, что он с закрытыми глазами спроектирует все как надо.

проц я пока что выбрал этот: AVR 8535 (для него на С вроде удобнее писать я слышал).

Цитата

(для него на С вроде удобнее писать я слышал).

Да. Его gcc должен поддерживать.

Добавлено 25.01.06, 14:06
В остальном -- предложить вариант -- мы предложили. В остальном -- выбор за тобой.

ок, большое спасибо за помощь.