Xenomai + LinuxCNC, EVL + LinuxCNC из исходников

[ua3nbw]

добавлю, чтоб на 4.19.y и 4.20.y заработал debug UART надо поправить в /boot/armbianEnv.txt :

Код: Выделить всё

verbosity=7
console=serial

[banches]

Очередной прыжок armbian. 09.01.19
sunxi-next теперь собирает с ядром 4.19.y
sunxi-dev соответственно с ядром 4.20.y

Последний стабильный вариант armbian/build для ядер v4.14.78 - v4.14.91
соответствует коммиту - 34ccb5d6250b86031dc77baf024d7a6186dc9493 от 08.01.19
Т.е.
Если имеется желание продолжать собирать с ядром v4.14.78 - v4.14.91

Код: Выделить всё

cd build
git checkout -b sunxi-4.14.78_91 34ccb5d6250b86031dc77baf024d7a6186dc9493

При этом сама система сборки armbian зафиксируется,
а источники будут продолжать обновляться. Их тоже можно зафиксировать.
Или регулярно вносить изменения в заплатки armbian/build/patch/{atf,u-boot,kernel}

Отлично,но напрашивается более полный ответ, как зафиксить источники. И где лежат эти коммиты ядер,например белее ранних?

[going]

Отлично,но напрашивается более полный ответ, как зафиксить источники. И где лежат эти коммиты ядер,например белее ранних?

Все источники управляются git. Документации на родном языке в сети хватает. Вопрос очень общий.
Просто напишите чего хотите добиться от armbian. Подскажу как это сделать оптимально.

[going]

Эпохальное событие в развитии двойного ядра.

Philippe Gerum выложил в ощий доступ новую реализацию двойного ядра "Ласточкин хвост" (Dovetail).
И библиотеку к его использованию.

https://www.xenomai.org/pipermail/xenom ... 40669.html

Перевод:

"Движимый болью, которую мы продолжаем причинять себе каждый раз,
когда нам нужно перебазировать I-pipe над недавним выпуском ядра,
я начал работать над определением его будущей замены.
Теперь, когда у нас есть реализация его преемника, работающего надежно,
мой следующий шаг-перебазировать порт Cobalt ARM на этом новом интерфейсе,
называемом ласточкин хвост [1].

Эта работа является частью больших усилий по переосмыслению способа интеграции
независимых программных ядер, таких как Xenomai, в основное ядро [2].

Это привело не только к реализации ласточкина хвоста, но и к демонстрации его
с Новым со-ядром в реальном времени, первоначально полученным из кобальта [3],
которое является простым и достаточно компактным, чтобы использоваться в качестве инструмента
обучения для всех, кто интересуется технологией двойного ядра на основе Linux.

Цель этой работы состоит в том, чтобы сделать dual kernel легким, по крайней мере,
максимально простым для людей, чтобы разрабатывать и поддерживать
свое собственное программное ядро выбора по сравнению с текущим ядром магистрали."

[1] https://evenless.org/dovetail/
[2] https://evenless.org/
[3] https://evenless.org/core/

--
Philippe.

[MX_Master]

Них.. не понятно, но очень интересно (:

[going]

Попытки подружить linuxcnc c xenomai у меня пока не принесли желаемого результата. А жаль.
Две проблемы.
Первая - это надо переписывать rtapi, что бы задачи реального времени работали в пространстве ядра.
Вторая - это процесс создания пакета debian переделать, а то он адаптирован к сборке на платформе и
пытается проверять установленное ядро в системе (uname -r), утановленные пакеты средствами apt.
Т.е. для кросс компиляции не подходит.
На сегодня linuxcnc собирается и заворачивается в архив, а на целевой платформе раcпаковывается,
что очень не удобно.

В этом случае, переделка linuxcnc на "Ласточкин хвост", он ориентирован на arm,arm64, имеет преимущества.

[MX_Master]

Я, кстати, вчерась читал, что бороться с linux за подобие RT в многоядерных чипах и не нужно. Всегда можно забрать у linux нужные ядра под свои Bare Metal задачи. И даже кусок ОЗУ под это дело отнять. Конечно, шина памяти и доступ к io будут общие, и ядра проца могут друг другу мешать. Но если грамотно разграничить их работу, проблем быть не должно.

Кстати, в современных ARM чипах бывает по несколько процессоров. И мелкие сопроцессоры есть. Так что даже наилучший режим RT от ядра linux может не дать такого эффекта, который можно получить на свободном сопроцессоре.

[going]

Всегда можно забрать у linux нужные ядра под свои Bare Metal задачи

В этом и состоит суть системы с двумя ядрами. cobalit работает на голом металле,
запускает РТ задачи и рулит всеми прерываниями,
позволяя ядру linux выполнять свою работу только тогда, когда эти ресурсы не требуются для РТ.
Это отличный инструмент для различных хотелок.
И да, когда несколько ЦПУ паралельно выполняют много задач РТ и неРТ общими ресурсами, должен рулить кто то один.

Вот интересное замечание про isolcpu:
https://evenless.org/core/caveat/
Ссылку можно скормить переводчику.

[going]

Так что даже наилучший режим RT от ядра linux может не дать такого эффекта, который можно получить на свободном сопроцессоре.

В случае с двойным ядром РТ режим обеспечивает не ядро Linux а со-ядро.
Можно написать свою РТ задачу, выделить для неё отдельное ЦПУ и отдать её со-ядру, задача будет запущена в РТ режиме.
И ресурсы общие будут разрулены корректно.

[MX_Master]

В случае с двойным ядром РТ режим обеспечивает не ядро Linux а со-ядро.
Можно написать свою РТ задачу, выделить для неё отдельное ЦПУ и отдать её со-ядру, задача будет запущена в РТ режиме.
И ресурсы общие будут разрулены корректно.

В этом и состоит суть системы с двумя ядрами. cobalit работает на голом металле,
запускает РТ задачи и рулит всеми прерываниями,
позволяя ядру linux выполнять свою работу только тогда, когда эти ресурсы не требуются для РТ.
Это отличный инструмент для различных хотелок.
И да, когда несколько ЦПУ паралельно выполняют много задач РТ и неРТ общими ресурсами, должен рулить кто то один.

Вот. Теперь понятно. Эти слова надо вставить аккурат под зелёным текстом в сообщении 144 (: Резюмируя сказанное, можно предположить, что linux будет играть роль гостевой ОС, а основной ОС будет bare metal прошивка.

А ведь у каждого чипа абсолютно разный набор регистров по управлению периферией. Эта вот bare metal прошивка должна будет всё это знать для запуска на разных чипах.

[going]

Эта вот bare metal прошивка должна будет всё это знать для запуска на разных чипах.

Тут в терминологии можно путаницу допустить. Что я похоже и сделал. Оставим термин "на голом металле" в покое.
Приведу пример. QNX, MacOS. В отличии от Linux, в этих полноценных операционных системах всё управляется микроядром.
Ядро маленькое, а значит быстрое. Оно запускает все процессы, управляет всеми прерываниями и распределяет ресурсы.
Драйвера, и др. это просто отдельные программы (процессы). Микроядро их связывает и они общаются напрямую.

Ядро linux большое и монолитное, драйвера внутри и\или подгружаются в виде модуля.
В случае с двойным ядром скорее уместно сравнение с хором.
Есть солист и есть хор, который под него подстраивается (подпевает).
Или с оркестром в котором один дирижёр и много музыкантов.
А результат - полноценное музыкальное произведение.

[Serg]

Не стоит рассматривать архитектуру ОС в отрыве от архитектуры железа, ибо именно периферия вносит основную "жопу" в RT. Например хорошие результаты показывают современные двухпроцессорные платформы с двумя XEON - у них у каждого своя собственная память и шина к ней. Если для RT на такой платформе выделить один процессор (не одно из ядер!), то результаты получаются очень хорошие.
Всяким ширпотребным платкам с ARM и x86-материнкам такое не светит в принципе, все процессы на них в любых ОС обречены на конкурентную борьбу, даже драйверы внутри одного ядра будут "гадить" друг другу.

[MX_Master]

Эх, как теперь жить, если ничего нельзя рассматривать в отрыве (:

Сергей, как вы считаете, а в ARM чипах, где есть два и более процессоров (rk3399 например). Будут ли они мешать друг другу, если один из них используется только для работы с GPIO и юзает только встроенную SRAM?

[going]

Всяким ширпотребным платкам с ARM и x86-материнкам такое не светит в принципе, все процессы на них в любых ОС обречены на конкурентную борьбу, даже драйверы внутри одного ядра будут "гадить" друг другу.

Вот снова прав добрый человек.
Но в новом подходе Philippe Gerum вроде как пытается решить эту проблему.
И ведёт речь о десятых долях микросекунды. На днях попробую это проверить.

Вчера, кстати прогнал тест на linux-5.0.5-ipipe + xenomai для архитектуры arm на процессоре A83T.
Ядро любезно сообщило, что аппаратный DMA отдыхает, а трудится виртуальный и далее ..... .
Т.е. в ядре недостаточно дров для работы реального железа.
Но даже в этом случае без Х11 задержки не превышают 10-12 микросекунд.
С Х11 в пространстве ядра 25 без нагрузки, 45-50 с нагрузкой. В пространстве пользователя ~200

[going]

Будут ли они мешать друг другу, если один из них используется только для работы с GPIO и юзает только встроенную SRAM?

Если в ядре существует драйвер GPIO поддерживающий реальное железо, который создаёт блочное устройство для РТ режима и реагирующий на IRQ, а так же
РТ задача, которая по таймеру генерит прерывание для этого блочного устройства и всё это крутится на выделенном ЦПУ то
вроде как ничего не должно мешаться под ногами.
Наверно и кеша ЦПУ в этом случае хватит? Как думаете?

[MX_Master]

Не не, без прерываний. Просто в бесконечном цикле читаем и пишем в регистры GPIO, а для данных используем только SRAM'ку. Если данных мало, то кэша хватит.

[going]

Просто в бесконечном цикле читаем и пишем в регистры GPIO,

Пока вразумительно ответить на это не могу. Надо подумать.
Что читаем? В какой момент времени пишем?

[MX_Master]

Читаем регистр состояния каждого GPIO порта, пишем туда же. Конечно, у каждого чипа своя архитектура шин и связь с модулем GPIO. Но, в общем случае, если мы из linux не будем дергать регистры GPIO напрямую, то помехи должны быть минимальны. В теории.

Ну, как UAVpilot придёт, он нам быстро все точки на i расставит. И будет прав (:

[going]

Немного почитал здесь:
https://evenless.org/core/user-api/thread/
В терминогоии автора, существует две полосы регулирования внутренняя и внешняя.
В каждой свой планировщик.
Внутриполосная для РТ задач.
А также в Linux всё есть файл. Порт gpio то же файл. Файл - блочное устройство.
Он должен быть открыт в контексте внутриполосного регулирования с помощю вызова предоставляемого библиотекой.
Далее РТ поток, запущенный в том же контексте, пишет в файл, по сути сразу в регистр gpio т.к. файл блочное устройство это ссылка на этот регистр.

[going]

Далее, продолжая логику, мы описываем в дереве обьектов имена пинов, которые должны быть открыты в РТ режиме.
например:

Код: Выделить всё

			rt-pins {
				pins = "PB4", "PB5", "PB6", "PB7", "PB8";
				function = "rt_gpio";
				phandle = <0x59>;
			};

Драйвер gpio ядра linux, при старте системы, с помощю функции rt_gpio создаёт файлы - блочные устройства с нужными именами.
А далее по букварю, в нужный момент файл устройство должен быть прикреплён к внутриполосному регулированию ... и т.д.