Как стать автором
Обновить

Комментарии 41

А с железом игрались? Ethernet тот же работает?
Ethernet работает, поддержка по умолчанию включена в ядро. То есть никаких действий не надо будет производить, после загрузки плата подхватит по DHCP адрес и все. Еще проверял UART, USB, GPIO. Что касается USB — тут надо добавить в ядро поддержку того, что именно вы хотите получить. Как добавить поддержку USB-флешек я описал в статье, если вам надо, к примеру, RNDIS — это делается отдельно. Поддержку GPIO тоже добавлял сам ручками, успешно работает.
при несоблюдении которых процессор мог полностью выходить из строя, причем не сразу, а со временем и в самый неподходящий момент

Подавали на порты напряжение раньше, чем на сам процессор?

Я делал этот проект несколько лет назад, сейчас так сходу все и не припомню. Но из того, что осталось в памяти:
1) Линию VBUS USB надо подключать к процессору через резистор 1 кОм. Про это нет ни слова в даташитах, но такое включение представлено в отладочных платах производителя. Я не углядел тогда этот момент и в итоге у части модулей выгорел USB. Причем выгорал он ни сразу — у некоторых модулей через месяц после начала эксплуатации, у некоторых через полгода, а некоторые вообще работают до сих пор. В новой ревизии железа я заложил этот резистор и проблем с USB больше не было.
2) У процессора AM4376 есть один коварный вывод WARMRST. Он вроде как должен использоваться для сброса какой-то внешней периферии после инициализации процессора. Я смотрел осциллографом, на нем действительно в этот момент проскакивает импульс. Я его использовал для сброса WiFi модуля с подтяжкой к питанию WiFi модуля, и вот тут да, возможно, на этот вывод напряжение приходило на несколько десятков микросекунд раньше, чем на процессор. По итогу ситуация была аналогична USB — у одних модулей через неделю, у других через полгода этот вывод выгорал и процессор оказывался неработоспособным. Однако если оставить этот вывод вообще без подтяжки, процессор вообще не запускался. Лучшим решением стало подтянуть в глубине платы этот вывод через 100 кОм к питанию процессора и забыть про него, а для сброса модулей использовать GPIO. В новой ревизии так и было сделано, за несколько лет ни одной аналогичной проблемы не возникло.
3) Следует помнить, что USB у техаса по умолчанию High Speed (это который 480 Мбит/с). Со всеми требованиями к разводке дифпар.
надо подключать к процессору через резистор 1 кОм

Может быть у вас VBUS просто превысил Absolute Maximum Ratings? Резистор в таком случае не даст выпалить схему при превышении напряжения.


на этот вывод напряжение приходило на несколько десятков микросекунд раньше, чем на процессор

Скажем, это проблема не только Sitara, ну и камней других производителей (NXP i.MX6UL как пример). Нежный техпроцесс, все дела.


по умолчанию High Speed

Так отключаемый же

Может быть у вас VBUS просто превысил Absolute Maximum Ratings? Резистор в таком случае не даст выпалить схему при превышении напряжения.

Если мне не изменяет память, то этот параметр для VBUS техаса равен 5,5 В. Ну, то есть как у большинства других устройств, работающих с USB. Кроме обычных ПК и ноутбуков никуда девайсы больше не подключались. При этом, в эти же самые ПК и ноутбуки подключались и другие устройства. Однако сгорал только USB техаса, и все стабилизировалось после установки этого резистора. Так что склонен думать, что дело именно в нем.

Скажем, это проблема не только Sitara, ну и камней других производителей (NXP i.MX6UL как пример). Нежный техпроцесс, все дела.

Кстати, там напряжение даже шло не напрямую, а через 10 кОм, даже это не спасало)

Так отключаемый же

Да, после того как загрузилась система. Однако если вы используете загрузку прошивки через USB с использованием встроенного бутлоадера, то, если я все правильно понял, все равно придется работать с High Speed.

НЛО прилетело и опубликовало эту надпись здесь
Конечно, ради него же все и затевалось :) Apt запустился на Debian (там про него в конце статьи пару строк). На Arch Linux вместо него pacman, тоже запустился после небольшой пляски с бубном, но с ним всегда так.

Эм… как раз таки файл dtb позволяет спокойно загружать и использовать дистрибутивы linux под практически любой ARM ну при условии конечно что поддержка есть в mainline ядре. Достаточно подсунуть правильный dtb.


А u-boot где на плате живет? Или он с sdcard подгружается? И нет ли уже собранного у производителя? А то иначе если поддержка в mainline ядре есть, то сводится к положить u-boot настроить его подпихнуть dtb kernel и rootfs

Эм… как раз таки файл dtb позволяет спокойно загружать и использовать дистрибутивы linux под практически любой ARM ну при условии конечно что поддержка есть в mainline ядре. Достаточно подсунуть правильный dtb.

Да вот я тоже был уверен, что это так. Поэтому первым делом и попробовал взять готовый dtb и подсунуть U-Boot ядро из дистрибутива Arch Linux. Однако все зависло на этапе Statring kernel… При этом ядро, собранное Buildroot, с тем же самым dtb успешно загружалось. Подозреваю, что проблема в адресах, куда кладется dtb и ядро. Однако пока не сумел разобраться. В исходниках dts вообще этих адресов не обнаружил. Буду благодарен, если вы можете сказать, куда следует копать.
А u-boot где на плате живет? Или он с sdcard подгружается? И нет ли уже собранного у производителя? А то иначе если поддержка в mainline ядре есть, то сводится к положить u-boot настроить его подпихнуть dtb kernel и rootfs

Да, и u-boot, и fsbl живут на sdcard. Про это написано в статье, да и другой памяти просто нет на плате)
У производителя есть репозиторий на GitHub, там есть исходники U-Boot. Однако я собирал U-Boot из официального репозитория, работает не хуже))
Однако все зависло на этапе Statring kernel…

Указывает на отсутствие dtb :) Не нашло dtb вот и результат. Там надо опции крутить в u-boot. Сначала надо грузить dtb потом kernel а потом же делать boot. Иначе будет такой вот ой.

Суда по строчкам типа «Loading Device Tree to cffec000, end cffff94a» перед Statring kernel, все-таки dtb он находит) Ну и я проводил эксперимент: брал один и тот же U-Boot, один и тот же скрипт загрузки, один и тот же dtb и менял только zImage. Если я брал zImage из дистрибутива Arch Linux, то все зависало на Starting kernel. Если брал zImage, собранный Buildroot — успешно запускалось. Подозреваю, что дело все-таки в адресах, куда грузится dtb. Возможно, ядро Arch Linux ищет дерево устройств не в том месте.

Скорее всего в адресах проблема да.

Спасибо. Полезно.
Лежит плата на STM32MP157A
Буду на ней управление станком чпу делать. С 5" экраном где громе текстовой инфы планирую 3Д отрисовку работы. Доступ по wifi. А то готовое что предлагают китайцы либо убого, либо запредельно дорого.
На м3 ставит ос нецелесообразно, а вот на м7 это уже может быть удобно в решении моей задачи чем писать прошивку с "0".
Но пока даже не рыл в эту сторону. Пока делаю механику станка.

Спасибо, но цнц мне не подходит. У меня grbl.
Распберри рассматривал, но отсутствие ацп неприемлимо. Нужно.

Обычно проще второй контроллер с АЦП поставить и малинку.

Да, ставят. Но:
1) Ставить более дорогой и более мощный девайс чтобы его потом еще и наращивать…
2) Между тем, что лежит в коробке с контроллерами "на всякий случай" и тем, что нужно покупать и ждать ещё больш_я разница.
3) В этой коробке еще esp пара и Atmel на Cortex-M3 лежит, но я решил иметь запас по производительности.
:)

Характеристики встроенного АЦП очень отвратные, как правило. Тогда уж поставить АЦП на SPI. Цена не сильно меняется, а плюсов много.

Согласен что не очень. О мерить выход датчика тока asc достаточно. Это ток шпинделя мерить, чтоб останавливать программу при закусывании и т п.

Математику на Малинке, а жесткий realtime — на голом железе. В принципе, как понимаю, в этом вся «фишка» главного героя статьи (я про SoC). На семерке (A7) — ось + математика крутится, на M4 — жесткий реалтайм. Давно использую такие связки ПК (все, что с полноценной ОС, от Винды до Openwrt) + контроллеры. Думаю, с 0 такой контроллер сделать почти не реально в «одни руки», очень долго. Можно взять за основу «Марлин», ту часть, которая за G-CODE отвечает. И был такой проект CNCLinux вроде назывался, не помню, лет 10 назад этим интересовался. Удачи Вам!

Да, оптимальный вариант.
С "0" можно. Библиотеки все есть. Парсер г кода, отрисовки задания, подсчет времени выполнения.
Я еще свое по результатам опыта хочу добавить:
1) Управление оборотами (а не мощностью как обычно) шпинделя
2) Контроль тока шпинделя. Если закусит, то экстренный стоп задания с запоминанием координат (позиционирование еще тот геморрой)
Ну и мого еще по мелочи.

Не стану этого отрицать, возможно, где-то и лежать на просторах интернета, но так сходу мне найти не удалось. Да и просто было интересно поковырять поглубже этот процессор :)
В таблице ошибка 151 не имеет CAN интерфейса
Да, действительно так. Спасибо за внимательность, таблицу подправил.
А как в этих процессорах организуется работа с разными архитектурами?
Ну, ведь М4 и А7 — весьма разные архитектуры и приемы работы с ними, соответственно, тоже разнятся. Я как привык с M4 — в CubeMX раскидать начальные настройки, а потом работать уже с bare metal, на крайняк с примитивной ОСРВ.
В случае же с линукс все совсем иначе. Как раз как в статье описано.
Вот и интересно, как работать с этими архитектурами одновременно? В статье про М4 ни слова, все про «более крутые» процессоры…

Ну все обычно просто: пингвин инициализирует железо, инициализирует маленькое ядро, закачивает в его оперативку программу и стартует его. Дальше по работе уже ничем не отличается. В зависимости от крутости камня сопроцессор может быть закрыт IOMMU (как DSP у TI AM5728), а может и нет (система PRU-ICSS на TI AM3358). Код от "большого" процессора для работы с периферией подходит и наоборот. А что, и то, и то — армы, и оба 32-разрядных.

Хороший вопрос! Здесь на Хабре была статья как раз на эту тему. Там подняли обмен между ядрами посредством виртуальных UARTов. Но у меня пока что не дошли руки это попробовать)

У здоровых людей для этого используется rpmsg


А, так в статье про него и речь. Хотя название "виртуальный UART" — это слишком

Доводилось работать с imx8 в котором есть m4 ядро в дополнение к A35. Там прошивка для m4 загружается u-boot в определенную область ОЗУ после чего запускается m4 ядро. Общение между ядрами через общую память. Есть модуль что может послать другому ядру прерывания. Поверх этого есть поддержка протоколоа rpmsg для обмена сообщениями через общую память. Переферия теоретически доступна обоим ядрам, есть специальный набор регистров где выставляются биты разрешения доступа к тому или иному блоку отдельно для Cortex A ядер и Cortex M ядра.
Итак, смотрим директорию u-boot/arch/arm/dts. В ней должен быть файл stm32mp157a-dk1.dtb


В этой директории есть только файлы .dts, .dtb нету. Может вы ошиблись?
dts — исходные файлы дерева устройств, а dtb — результат их компиляции. Попробуйте выполнить сборку U-Boot, после первой сборки у вас в этой директории появятся файлы dtb.
Да, после сборки он появится, но вы то описываете процесс подготовки к сборке, а на этом этапе его ещё нет. Я про это хотел сказать, и наверное стоит исправить.
Да, это так. Внес в статью соответствующее примечание. Спасибо.
Спасибо. И спасибо за статью, благодаря ей у меня что-то сдвинулось с мертвой точки. Сложноватая плата.

Будет ли продолжение про взаимодействие с М4?
Про взаимодействие с M4 я давал ссылку на статью с Хабра чуть выше в комментариях. У меня пока что не стояло задачи работы с этим ядром, но если дойдут руки и там будет что-то интересное — возможно, об этом тоже будет статья.
Отличная статья. С удовольствием ознакомился. Сам вожусь с DK2, статью мою здесь упомянули. :) <Вот эта «habr.com/ru/post/493884»> Но пока выйти на построение нормального графического интерфейса не получается. В сборке OpenLinux, которая в Стартер пакете, используется Wayland, писать графику можно на GTK. Но у меня не получилось корректно управлять положением окон на экране. Написал на Community, пока нормального ответа не пришло :( community.st.com/s/question/0D53W000004JZeGSAW/gtkwindowmove-does-not-work-
Поставил сборку на основе графического сервера Х11. Не получается связаться с сервером. :( community.st.com/s/question/0D53W0000080dmqSAA/i-have-2-problems-on-installed-stexampleimagex11
Пока в раздумьях, что же делать дальше. :)

Спасибо!
С графикой на этом процессоре пока не имел дело, у меня отладка без дисплея, но если вам удастся её поднять — с удовольствием прочитаю статью на эту тему :)
Пытаюсь повторить ваш путь, и остановился на замене rootfs из Arch или Debian.
Не понятно, откуда конкретно вы брали root? У debian нашел только ссылки на установочные iso полной системы или netboot. Они вроде бы есть под arm, обозначены как armhf.
У Arch ссылки на x86_64 образы.
Если не сложно, уточните пожалуйста этот момент.

Поскольку с момента написания статьи прошло уже прилично времени, я не делал изменений в buildroot для сборки ядра 4.19, а собрал со свежим ядром. На данный момент это 5.8.13
Для теста я сразу записал на карту готовый sdcard.img.
Система загрузилась, но отличается разметка разделов — нет раздела kernel. На карте разделы fsbl1, fsbl2, ssbl, rootfs. И образ rootfs.ext4 является симлинком на rootfs.ext2
Rootfs для archlinux можно взять с официального сайта, в статье есть ссылка. Debian, насколько помню, я брал отсюда.
По вопросу версии ядра — будьте внимательны, я в статье отмечал, что в версии buildrootа без патчей от STM у меня не вся переферия работала.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории