Всем доброго дня. Пускал ли кто 2 ядра в baremetal, не в операционке? Если да, подтолкните в правильном направлении - литература там, может даже код загрузки второго ядра (если не жалко), ну и вообще любую информацию. Нужно запустить совершенно разные программы на разных ядрах.

Нашли решение ? не могу даже создать проект для bare metal. ds-5 просто не видит нужный toolchain .

Подниму тему - тоже интересует данные вопрос.
Есть ли какие-то сдвиги? Хоть что-нибудь, хоть светодиодиком поморгать... Хотя бы на 1 ядрышке

Хотя что-то вроде здесь есть https://developer.arm.com/products/software...elopment-studio

Вчера как раз дошёл до моргания светодиодом на одном ядре с запуском проги через дебагер без старта прелоадера. Пришлось немного помучать LD скрипт потому что он изначально рассчитан на работу из внешней памяти. А она в момент старта ещё не работает. Но есть 64К встроеной памяти. В общем переназначил некоторые и зоны и указал их размеры. Прога компилится через мэйк файл и запускается через дебагер нормально. Попробовать загрузку проги с пока не удалось нету под рукой картридера.
Если интересно вечером могу целиком пример привести.


В теорри скорей всего второе ядро будет висеть в ресете(проверить не могу девкит сейчас дома)
https://www.altera.com/en_US/pdfs/literatur...ne-v/cv_5v4.pdf
на 131 странице регистр 0xFFD05010(mpumodrst) в нём есть бит отвечающий за то находится ли ядро в ресете(по документации после старта второе в ресете).

Когда уберешь этот бит по идее ядро должно стартануть и начать выполнять код по адресу 0x00000000 там изначально лежит BootROM. Есть регистр которые переносит туда OnChip RAM. Соотвественно её надо туда переключить и стартануть ядро после этого оно начнёт исполнять код. Дальше у ядра по идее должен быть регистр по которому можно узнать на каком ядре выполняется код и уже там разруливать что на каком ядре работает.

Адрес который указывает с какого места стартовать второму ядру хранится в регистре cpu1startaddr на 240 странице вышеуказанного хэндбука.

Что потребуется кроме указанных регистров:

• в скрипте линкера выделить место под стек второго ядра
• если используются прерывания, то проинициализировать и включить их для каждого ядра (глобальные инициализацию и включение делает 0-е ядро)
• если используются кэши, то есть отличия в настройках MMU (.shareable = ALT_MMU_TTB_S_SHAREABLE для кэшируемой области). также нужно включить SCU, он будет следить за когерентностью кэшей данных.
• если инициализация FPGA идет с HPS, то ее надо делать до включения MMU (т.е. до предыдущего шага)

Можете залить куда-нибудь примерчик, а то вожусь как дурак и не пойму что не так делаю.
Спасибо

Кстати а куда в случае bare metal приложения заливается прошивка? В Boot ROM (к нему не относится read only?)? Можно ли его прочитать, аля flash STM32?

на любую флешку, подробности в приложении "Booting and Configuration" к мануалу. с памятью можно не возиться, если взять готовый предзагрузчик.

Хочется именно в boot ROM, ибо с осями я никогда не работал и не знаю как должна программироваться флешка. Точнее можно сказать так: Есть опыт только с микроконтроллерами и я ожидаю (пока что) аналогию с ними. Сдается мне, что microSD мне придется зашивать с компа не через Blaster, а этого я делать пока что не умею

И еще интересный вопрос - сколько раз может перезаписываться внутренняя 64кбайта ROM? Вроде в мануале не написано

Boot ROM никто не переписывает. В мануале расписано, как загрузчик, сидящий в Boot ROM ищет по разным местам код для продолжения. Самые простые варианты - QSPI и uSD. Для QSPI указываются смещения, для uSD создается специальный раздел. QSPI шьется бластером, а на карточку и вовсе файл закидывается через кардридер.

1. То есть программирование идет только на флешку? (у меня DE0-nano soc).

2. А в каком виде должна находиться прошивка на SD? Я в последнем разделе (Booting and configuration) не нашел (может плохо искал?), там есть биты BSEL, которые отвечают за устройство загрузки и еще какая-то инфа, бегло пробежавшись не увидел как должно быть.

3. А как тогда идет отладка? Точнее каким образом записывается на карту программа? Ведь что бы закинуть файл на SD там нужно файловую систему поднять... А отлаживать потом как? Или можно каким-то софтом залить? В примерах видел только через линкус, и то там образ заливался.

4. Кстати VBKesha упоминал про то, что сначала работать с внешней памятью нельзя (контролер не инициализировал ее, это понятно), но можно работать с 64 встроенной RAM. Вот тут можете в 2х словах сказать откуда выполняется программа? Из ОЗУ, кто ее туда копирует? То есть не как в микроконтроллере из flash? А как в этом случае работает программа из ROM?

Спасибо)

Программируется флеш, отладка идет из ОЗУ. Прошивка на uSD лежит в виде обычного файла на FAT-разделе. Предзагрузчик лежит на разделе с типом FS 0xA2. Если вы делаете свой предзагрузчик, либо уверены, что упихаете код в 60 KB, то можно обойтись без FAT. В примерах с линуксом можно как раз посмотреть на разметку SD-карты. Только для bare-metal вам не нужен раздел с корневой FS линукса. Программа из ROM выполняется при старте, ее задача - найти preloader и скопировать его в OCRAM, не более. В случае отладки загрузку preloadera (и остальных компонентов программы, если имеются) в память выполняет скрипт отладчика.

На DE0-nano-soc да, откуда грузить проц выбирается через ноги BSEL а на DE0-nano-soc они запаяны перемычками и поменять их нельзя. Только SD Карта


Биты BSEL это пины. Прошивка, тут всё интересней изначально система грузит прелоадер, прелоадер лежит на разделе флешки с определенным ID, то есть по сути прелоадер лежит не на файловой системе а как RAW данные в спец разделе. Есть ещё вариант когда просто прелодер лежит в начале флешки но тогда там вообще не будет разделов и прочего. Прелоадер по сути это первая внешняя прога которую стартует этот проц. На этом в целом может всё и закончится то есть прелоадер будет основной прогой. Если же нет то дальше прелоадер решает как и что грузить.


Вот тут начинается веселье. Во всех смыслах этого слова. Дебаг идёт через дебаг скрипт. Суть скрипта всякими манипуляциями довести проц до твоей программы и уже на ней сделать брякпоинт. Делает он обычно это так сначало на карту пишешь прелоадер. Дальше стандартный скрипт расписан так:
1. Делается ресет процу.
2. Ставит бряк на процедуру прелоадера которая начинает загрузку приложения с карты.
3. Загружает в память elf(они его зачем то зовут axf) в память уже инициализированого чипа.
4. Ставит точку стартка на main приложения.

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


Есть BootROM(поменять его нельзя, по крайней мере нигде не описано как) у него простой алгоритм:
1.Провести минимальную инициализация.
2. Прочитать BSEL выбрать откуда грузиться.
3. Поискать заголовок прелоадера, если нашёл то загрузить его в OCRAM(те самые 64 килобайта) передать управление на него.
По идее если не смог загрузится откуда либо он должен попытаться загрузится из FPGA но что то у меня это не сработало.
Вот в этом документе описано подробней что и как https://www.altera.com/content/dam/altera-w...re/an/an709.pdf

PS. В Altera'вских примерах нашёл пример MPL прелоадер, если оттуда вырезать загрузку с флешек, и поддержку фата(чем я собираюсь на днях заняться), то как раз получится каркас Baremetal приложения работающего без загрузчика(само по себе загрузчик), которое можно будет отлаживать без танцев с бубном но с ограничением в 64Килобайта на приложение.

С прелоадером и вообще с картой загрузки, что откуда стартует я разобрался.



Но ведь с компа нельзя будет загрузить на флешку что либо без поднятия файловой системы. Хотя может можно это через цпец софт сделать...



Хм. Могли бы хотя бы сделать полной отладкой вместе с BootRom. А то так получается скрипт хз что делает и какими-то путями приводит к main.
А вот интересно, ведь прелоадер имеет тоже свой main или я не прав? Сам прелоадер пишется вместе с основной прогой или отдельно? Вообще исходя из мануала как сделать "BareMetal" приложение я так и не понял что и куда там зашивается. А учитывая что не написано "вытащите флешку, залейте на нее что-нибудь и воткните обратно" становится еще менее понятно. Более того в нескольких примерах была обычная эмуляция без работы реальной железки. Прям тайна какая-то.



64кб связано с размером OCRAM? То есть проц просто загрузит в нее приложение, оставит в ней место для кучи и стека и будет выполянть? Если он выполняет приложение из OCRAM тогда я не понял - если код и RO data приложения будет весить близко к 64кб, то где он возьмет место для стека и кучи?

Отпишитесь по результатам как у вас получилось чего. А то жалко получается - FPGA легко программируется, вообще без проблем, а тут "Не въедешь" © =)

Спасибо

ps. К сожалению я чувствую глубокий провал по знаниям в область процессора (именно устройства таких софтверных 1ГГц+), выполнения кода из RAM (хотя в STM32 это делается очень просто и там мне все понятно), работа кешей (вроде понятно что и для чего, но каким образом идет их работа и откуда проц знает есть там нужная ему инфа или нет - не понятно) ну и еще местами. Все до Архитектуры компьютера от Харрис добраться не могу..