LinuxCNC + Orange Pi (allwincnc)

[MX_Master]

Победил проблему с кривым копированием. Сделал копию папки /home/cnc/machinekit, оригинал папки удалил, переименовал копию в оригинал. Теперь копируется всё правильно.

Перезалил архив с образом opipc_machinekit_8G.rar (641 Мб).
Кто скачал предыдущий, перекачайте, пожалуйста.

[MX_Master]

Год назад спецы из bootlin, оказывается, смогли воплотить в жись OpenGL драйвер mainline ядра для чипов Allwinner на основе бинарников с закрытыми исходниками.

Надо попробовать - https://bootlin.com/blog/mali-opengl-su ... ine-linux/ . Нам бы не помешала поддержка OpenGL.

[donvictorio]

образ только на H3 встанет?
там просто opi кучка.

[MX_Master]

образ только на H3 встанет?
там просто opi кучка.

Screenshot_33.png

У каждой платы с H3 свои компоненты. Разные контроллеры питания, например. Разное кол-во портов и включённых устройств. Эти особенности учитываются патчами при сборке. Образ от другой платы может завестись, но ошибки в работе однозначно будут. Собрать по новой легче, чем исправлять ошибки вручную.

[donvictorio]

понял, знач фокусировка на OP PC http://www.orangepi.org/orangepipc/

[nevkon]

Кстати у OPi PC та же распиновка что и у OPi One?

[MX_Master]

Кстати у OPi PC та же распиновка что и у OPi One?

та же, на первый пин указывает белая стрелка

[svb]

Кстати у OPi PC та же распиновка что и у OPi One?

Кстати, все распиновки на Апельсинки есть тут

[going]

Не хватает времени на несколько проектов одновременно.

Может попробуем разделить задачи. Я смотрю народ заинтересовался.
Коллективно решать вопросы веселее. Разные взгляды, разный опыт.
Надо только задачи сформулировать корректно.

[MX_Master]

Может попробуем разделить задачи. Я смотрю народ заинтересовался.
Коллективно решать вопросы веселее. Разные взгляды, разный опыт.
Надо только задачи сформулировать корректно.

Два основных направления для тюнинга:

1. видеодрайвер (OpenGL и т.д.)
2. сопроцессор (генератор импульсов, счётчик импульсов и т.д)

[going]

Два основных направления для тюнинга:

А с "RT" всё устраивает?

[MX_Master]

А с "RT" всё устраивает?

Вполне.

Сейчас основной процессор рисует картинку вместо видео процессора. И шаги тоже основной проц генерирует. При этом ещё кучу всего считает. Поэтому основной интервал и latency- прыгают и скачут вплоть до 100 мкс. Вощем, все дела, которые упали на плечи основного проца, надо максимально распределить между тремя процессорами - arm, mali, arisc.

[solo]

сопроцессор (генератор импульсов, счётчик импульсов и т.д)

даешь сопроцессорный ногосмыкательный - ногодрыг

[going]

При этом ещё кучу всего считает. Поэтому основной интервал и latency- прыгают

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

latency- прыгают

потому, что сталкиваются с работающим процессом у которого механизм вытеснения
не работает или работает не корректно.

PS. latencytop покажет те процессы, которые плохо вытесняются.
sudo apt-get install latencytop

[MX_Master]

Я вижу, ты уже определился с тем, что хочешь делать (: Задачи можно было не формулировать

[going]

Я вижу, ты уже определился

Просто в настоящее время занимаюсь "RT" процессами.
Затем в планах mali прикрутить. В этом смысле да, определился.

А задачи, наверное по подробнее стоит сформулировать.
Хотелось бы понять как нагрузку

распределить между тремя процессорами - arm, mali, arisc.

У меня пока "тёмный лес" в голове по данному вопросу.

[MX_Master]

В общем виде, всем всё понятно. Видео выводом должен по максимуму заниматься MALI. Выводом/вводом с помощью GPIO должен заниматься ARISC. Всё остальное - ARM. Я думаю, что список задач должен быть, но важнее будет список багов и фич. И под каждым пунктом этого списка можно будет составить свой мелкий список задач.

На данном этапе предлагаю просто обозначить, кто и чем хочет и может заняться.

C mali я ещё не работал, поэтому лично для меня это будет трудновато. Что касается ARISC - мне будет проще. Но начал я разработку не с того места, надо переделать и ввести в код строгую модульность. Вощем, я могу снова заняться ARISC прошивкой, составить список багов/фич. Вроде бы, neller тоже интересовался темой ARISC.

[svb]

Я как программер полный нуль... Так, подправить очевидные ляпы при наложении патчей
Но в качестве тестера готов себя предложить.
Также мне видится необходимым поудалять ненужные пакеты из дистриба. Этим тоже могу заняться.
Доделать автоматическую сборку чтобы автоматом включалась туда MachineKit с демопримерами от MX_Master...
(на текущий момент у меня уже генерится сборка Jessie c интегрированным MachineKit, то есть не надо ее инсталировать после первого логона в систему)
Ну вобщем в таком ключе что-нибудь

[MX_Master]

Раз пошла такая масть, можно сделать свой форк armbian/build куда-ньть в отдельный аккаунт github'a. Назвать аккаунт что-то типа orangecnc. Туда же залить репу для ARISC.

[going]

можно сделать свой форк

Дело пошло !
Форк делать не рекомендую. "Армбиан" сильная команда. И система сборки у них на уровне.
Эта система постоянно развивается.
Проще вникнуть в ихнее описание этой системы и подкорректировать пару скриптов. Оно там позволяется.
А эти изменения\дополнения можно оформить в GIT.
Например:
Если собирать "next" то система тянет из git последнее актуальное ядро и складывает в
~/build/cache/sources/linux-mainline/linux-4.14.y
В этом случае версия ядра почти всегда опережает версию "RT" patch.
Я скачал последний, актуальный патч и соответствующий архив ядра с kernel.org
Патч patch-4.14.39-rt29.patch.xz распаковал в папку ~/build/userpatches/kernel/sunxi-next, а архив ядра положил в ~/build/cache/sources/linux-mainline/
В скрипте указал, что собирать надо не linux-4.14.y а linux-4.14.39
И добавил пару строчек. Перед началом сборки надо удалить папку linux-4.14.39, если она существует и распаковать исходный архив.
В оригинале папка с исходниками ядра чистится командами GIT.
Таким образом система сборки всегда актуальна, для конкретного ядра можно добавлять свои патчи и время от времени
переезжать на новую версию.

PS. Могу на себя взять ядро и mali. У меня вроде бы всё собирается, но надо чтобы система это понимала
(драйвер для Х11) и всё это в пакет завернуть.