Комментарии 41
при несоблюдении которых процессор мог полностью выходить из строя, причем не сразу, а со временем и в самый неподходящий момент
Подавали на порты напряжение раньше, чем на сам процессор?
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.
Эм… как раз таки файл 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. Иначе будет такой вот ой.
Спасибо. Полезно.
Лежит плата на STM32MP157A
Буду на ней управление станком чпу делать. С 5" экраном где громе текстовой инфы планирую 3Д отрисовку работы. Доступ по wifi. А то готовое что предлагают китайцы либо убого, либо запредельно дорого.
На м3 ставит ос нецелесообразно, а вот на м7 это уже может быть удобно в решении моей задачи чем писать прошивку с "0".
Но пока даже не рыл в эту сторону. Пока делаю механику станка.
Спасибо, но цнц мне не подходит. У меня grbl.
Распберри рассматривал, но отсутствие ацп неприемлимо. Нужно.
Обычно проще второй контроллер с АЦП поставить и малинку.
Да, ставят. Но:
1) Ставить более дорогой и более мощный девайс чтобы его потом еще и наращивать…
2) Между тем, что лежит в коробке с контроллерами "на всякий случай" и тем, что нужно покупать и ждать ещё больш_я разница.
3) В этой коробке еще esp пара и Atmel на Cortex-M3 лежит, но я решил иметь запас по производительности.
:)
Да, оптимальный вариант.
С "0" можно. Библиотеки все есть. Парсер г кода, отрисовки задания, подсчет времени выполнения.
Я еще свое по результатам опыта хочу добавить:
1) Управление оборотами (а не мощностью как обычно) шпинделя
2) Контроль тока шпинделя. Если закусит, то экстренный стоп задания с запоминанием координат (позиционирование еще тот геморрой)
Ну и мого еще по мелочи.
github.com/meta-debian/meta-debian
rcn-ee.com/rootfs/eewiki/minfs
Ну, ведь М4 и А7 — весьма разные архитектуры и приемы работы с ними, соответственно, тоже разнятся. Я как привык с M4 — в CubeMX раскидать начальные настройки, а потом работать уже с bare metal, на крайняк с примитивной ОСРВ.
В случае же с линукс все совсем иначе. Как раз как в статье описано.
Вот и интересно, как работать с этими архитектурами одновременно? В статье про М4 ни слова, все про «более крутые» процессоры…
Ну все обычно просто: пингвин инициализирует железо, инициализирует маленькое ядро, закачивает в его оперативку программу и стартует его. Дальше по работе уже ничем не отличается. В зависимости от крутости камня сопроцессор может быть закрыт IOMMU (как DSP у TI AM5728), а может и нет (система PRU-ICSS на TI AM3358). Код от "большого" процессора для работы с периферией подходит и наоборот. А что, и то, и то — армы, и оба 32-разрядных.
У здоровых людей для этого используется rpmsg
А, так в статье про него и речь. Хотя название "виртуальный UART" — это слишком
Итак, смотрим директорию u-boot/arch/arm/dts. В ней должен быть файл stm32mp157a-dk1.dtb
В этой директории есть только файлы .dts, .dtb нету. Может вы ошиблись?
Будет ли продолжение про взаимодействие с М4?
Поставил сборку на основе графического сервера Х11. Не получается связаться с сервером. :( community.st.com/s/question/0D53W0000080dmqSAA/i-have-2-problems-on-installed-stexampleimagex11
Пока в раздумьях, что же делать дальше. :)
Не понятно, откуда конкретно вы брали 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
STM32MP1: U-Boot, Buildroot, Arch Linux и немного Debian