Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Изменено пользователем GenaSPB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Quote

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


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

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

 

3 hours ago, MrBearManul said:

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

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

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

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

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

Изменено пользователем baritono

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 hours ago, mantech said:

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

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

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

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

Изменено пользователем baritono

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 hours ago, mantech said:

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

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

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

Изменено пользователем baritono

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

allwincnc.github.io

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

15.05.2021 в 21:10, mantech сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...