Jump to content

    
baritono

Многопоточность в загрузчике ARM

Recommended Posts

Допустим, есть желание перенести сравнительно несложную программу управления станком на многоядерный ARM - например, Rockchip RK3399. Но не заморачиваться при этом с RTOS, т.к. управление задачами и периферия не нужны. Насколько я понимаю, проще всего взять исходники какого-нибудь загрузчика, выбросить лишее, добавить нужное. Но в многопоточность загрузчик вряд ли умеет. Кто-нибудь делал запуск потоков "руками" на других ядрах в ARM? Или хотя бы где почитать про это? Гугление не помогло, вопросы находятся, ответы нет.

Share this post


Link to post
Share on other sites

Боюсь в таком случае количество потоков будет ограничено количеством ядер...

Я делал. Руками. На stm32mp1 и на xylinx zynq.

После сброса все ядра начинают работать по одному и тому же коду. Ядро может узнать свой номер и в зависимости от э ого или продолжать выполнение пользовательского кода или ждёт... ждёт обычно на команде wfe. Дождавшись, откуда-то (у разных производителей по разном) читает адрес куда идти и переходит к пользователтскому коду.

Контроллер прерываний GIC для каждого источника прерывания хранит маску какому ядру можно передавать  запрос. 

Edited by GenaSPB

Share this post


Link to post
Share on other sites
44 минуты назад, baritono сказал:

Допустим, есть желание перенести сравнительно несложную программу управления станком на многоядерный ARM

Ага, вы всё-таки продолжаете разработку ЧПУ)

44 минуты назад, baritono сказал:

Но не заморачиваться при этом с RTOS, т.к. управление задачами и периферия не нужны. Насколько я понимаю, проще всего взять исходники какого-нибудь загрузчика, выбросить лишее, добавить нужное.

И снова у вас всё перемешано: ОСРВ, периферия, загрузчики...

44 минуты назад, baritono сказал:

Кто-нибудь делал запуск потоков "руками" на других ядрах в ARM?

Делал. На двухядерном LPC4337 в далёком 2014 году. Всего два ядра.

 

З.Ы. Вы бы объяснили, что вам нужно. Ваши конечные цели совершенно непонятны. Следовательно, дать вам какой-либо ответ представляется весьма сложным. Попробуйте задать вопрос, используя не непривычные для вас слова (ОСРВ, загрузчик и т.п.), а привычные. А ещё лучше, задайте вопрос, используя просто обычные слова. Тогда, может быть, вам и совет дадут как достигнуть цели. А не будут отвечать на селекционированные вопросы, ответы на которые вам вообще могут не пригодиться.

Share this post


Link to post
Share on other sites
Quote

Боюсь в таком случае количество потоков будет ограничено количеством ядер...


Я делал. Руками. На stm32mp1 и на xylinx zynq.
После сброса все ядра начинают работать по одному и тому же коду. Ядро может узнать свой номер и в зависимости от э ого или продолжать выполнение пользовательского кода или ждёт... ждёт обычно на команде wfe. Дождавшись, откуда-то (у разных производителей по разном) читает адрес куда идти и переходит к пользователтскому коду. Контроллер прерываний GIC для каждого источника прерывания хранит маску какому ядру можно передавать запрос.

Большое спасибо, картинка проясняется. По одному потоку на ядро и нужно, без какого-либо шедулинга.
 

 

3 hours ago, MrBearManul said:

Ага, вы всё-таки продолжаете разработку ЧПУ)

И снова у вас всё перемешано: ОСРВ, периферия, загрузчики...

Делал. На двухядерном LPC4337 в далёком 2014 году. Всего два ядра.

З.Ы. Вы бы объяснили, что вам нужно. Ваши конечные цели совершенно непонятны.

Интересно, отличается ли Ваш опыт от опыта GenaSPB. Конечные цели слишком далеко лежат, чтобы обсуждать их здесь.

Edited by baritono

Share this post


Link to post
Share on other sites
43 минуты назад, baritono сказал:

отличается ли Ваш опыт от опыта GenaSPB

Ествественно. @GenaSPB живёт в одном городе, а я в другом. Мы никогда лично не общались, кроме форума. Я думаю, что отличается. И сильно.

44 минуты назад, baritono сказал:

Конечные цели слишком далеко лежат

Ой, не надо этих пафосных выражений))) Любая цель может быть выражена десятью предложениями... Хотя бы попробуйте. Что толку от того, что вы интересуетесь деталями при постройке космического корабля.

Share this post


Link to post
Share on other sites
1 час назад, baritono сказал:

По одному потоку на ядро и нужно, без какого-либо шедулинга.

Да ладно))), а как вы синхронизировать-то их будете, или они вообще "своей жизнью" жить будут? Лезть к портам когда попало, к другой периферии, диску и пр... :biggrin:

Зачем все эти ядра, когда можно простой переключатель контекста использовать на 1м быстром ядре??

5 часов назад, baritono сказал:

ARM - например, Rockchip RK3399.

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

Edited by mantech

Share this post


Link to post
Share on other sites
58 минут назад, mantech сказал:

Зачем все эти ядра, когда можно простой переключатель контекста использовать на 1м быстром ядре??

Вы разве не поняли ещё?)))) Человеку не нужна работа с периферией)))

59 минут назад, mantech сказал:

да и для станка это очень жирный оверхед

Но можно использовать чисто программные таймеры)

Share this post


Link to post
Share on other sites
41 минуту назад, MrBearManul сказал:

Человеку не нужна работа с периферией

Точно, забыл)))

43 минуты назад, MrBearManul сказал:

Но можно использовать чисто программные таймеры)

Кстати, да, переключатель контекста на 1м ядре для этого не подходит...

Share this post


Link to post
Share on other sites
5 hours ago, mantech said:

Да ладно))), а как вы синхронизировать-то их будете, или они вообще "своей жизнью" жить будут? Лезть к портам когда попало, к другой периферии, диску и пр... :biggrin:

Зачем все эти ядра, когда можно простой переключатель контекста использовать на 1м быстром ядре??

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

Камни эти у меня лежат без дела. Кроме дрыганья ногами пока ничего не нужно. Синхронизировать потоки тоже не нужно, хотя при когеррентном кэше это элементарно. Данный камень довольно давно поддерживается Linux mainline kernel, так что и без доков и многое другое можно. А станок стоит как 20 таких SBC.

Edited by baritono

Share this post


Link to post
Share on other sites
3 часа назад, baritono сказал:

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

Что вам это даст, если вы на голом камне свою программу будете делать? Из линукса исходники выдирать? Это далеко не просто, уж поверьте мне, я в теме...

3 часа назад, baritono сказал:

Кроме дрыганья ногами пока ничего не нужно. Синхронизировать потоки тоже не нужно

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

Share this post


Link to post
Share on other sites
9 hours ago, mantech said:

Что вам это даст, если вы на голом камне свою программу будете делать? Из линукса исходники выдирать? Это далеко не просто, уж поверьте мне, я в теме...

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

Нет ни диска, ни G-кодов, ни синхронизации. Один поток с управляющей программой на C, на другом индикация и логи. У второго доступ к данным первого только на чтение.

Edited by baritono

Share this post


Link to post
Share on other sites
6 часов назад, baritono сказал:

У второго доступ к данным первого только на чтение.

Ну, если это действительно так упрощено, может и заработает...

Share this post


Link to post
Share on other sites

allwincnc.github.io

Allwinner H3/H5/H6 + Armbian + rt-preempt linux kernel + LinuxCNC + ногодрыг на свободном RISC ядре

Чуть позже хочу замутить такое же на RK3399. Там свободных (cortex A/M) ядер заметно больше. Возможны, даже варианты. 

Share this post


Link to post
Share on other sites
3 часа назад, MX_Master сказал:

Возможны, даже варианты. 

Да там целый квест пройти надо, чтоб все это установить и сконфигурировать... Про использование "ногодрыг на свободном RISC ядре" - вообще не понял это же проприентарное ядро...

Share this post


Link to post
Share on other sites
15.05.2021 в 21:10, mantech сказал:

Про использование "ногодрыг на свободном RISC ядре" - вообще не понял это же проприентарное ядро...

Доки на это дело временами есть в тырнетах. Поэтому нет ничего странного в том, что можно юзать отдельное ядро управления спящим режимом для чего-то другого.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.