Всем доброго дня. Пускал ли кто 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 это делается очень просто и там мне все понятно), работа кешей (вроде понятно что и для чего, но каким образом идет их работа и откуда проц знает есть там нужная ему инфа или нет - не понятно) ну и еще местами. Все до Архитектуры компьютера от Харрис добраться не могу..

В комплекте софта для этого чипа идёт утилита alt-boot-disk-util.exe которая умеет писать прелоадер, но раздел всё равно должен быть уже создан какой нибудь прогой.


Да в принципе дебаг скрипт вполне себе текстовый файл просто с набором команд дебагера. Имеет ли прелоадер main зависит от самого прелоадера, MPL имееет, а тот что идёт с U-Boot вроде бы нет. Пишется он обычно без проги и потом уже загружает её. Про флешку не написали потому что если уйти от DE0-Nano-SoC то чип может грузится ещё и из QSPI/NAND/FPGA а там обычно файловых систем нет, и прелоадер может брать прогу по каким либо адресам. Вообще это проц серии A их использование обычно подразумевает использование операционки а не чистый BareMetal вот поэтому и столько проблем.



По сути да BootROM загрузит прогу и стартнаёт её, вот поэтому по манулам обычно всё разбивают на этап BootROM->Preloader->Soft. Прелоадер обычно инициализирует DDR, и уже в неё может закинуть основную программу и стартануть выполнение чтобы на всё хватало.


Тут выполнить прогу из RAM тоже не проблема, грузишь дебагером прогу в RAM и выполняешь, основная проблема(для меня), это инициалировать процессор, там куча заморочек что проще в итоге взять готовый инициализатор и использовать чем пытаться это самому сделать.

Вот и я тоже так буду делать, но из за того, что я дотошный и хочу понять все, я попытаюсь разгрести ту инициализацию, что написана в готовом. Это будет определенно проще и быстрее, чем с 0 писать

А альтеровской HWLib кто нибудь пользуется?
Это ведь как раз либа для упрощения работы с железом голым приложением?

Я смотрю, у Xilinx на Zynq вроде больше под GUI все заточено - мультиплексирование пинов HPS, к примеру.
А у Альтеры только ручками...

И ещё вопрос возник - применительно к процессорной системе HPS.

Каким образом, к примеру, конфигурируются GPIO пины (или остальные периферийные пины)?

Сначала прочитал, что всё на уровне софта записью в регистры (пинмукс, входы\выходы), то есть как в микроконтроллерах.

А сейчас на сайте RocketBoards.org прочитал вот это:

Написано, что наоборот - всё настраивается в Qsys.
Запутался...

я пользуюсь. главный недостаток - слабо документирована, с ниосом не сравнить.

конфиг для предзагрузчика берется из qsys, а он уже все через регистры настраивает

Угу, мне тоже показалось, что даже ниос лучше поддержан, чем соки

Частоты всех модулей по умолчанию какие получаются?
В настройках GUI прелоадера нет ни слова об этом.
Посмотрел здесь - проц на 800 МГц, и остальные модули расписаны.
Не знаю, совпадает ли с платой DE1-SoC.

Настройки компонента в qsys смотрите, вкладка HPS Clocks/Output Clocks. Если нужно в программе частоты узнать, то в hwlib есть соотв. функции

Спасибо, я пока в квартус не заходил даже, после MAX10.
С софтовой частью HPS разбираюсь.

Смотрю, без прелоадера даже не стоит заморачиваться с "ручной" инициализацией железа под bare metal приложение?
В силу слабой документации в первую очередь.

А для прелоадера нужные исходные файлы тоже квартус генерирует, или это где-то в другом месте делается (ручками)?
BSP-Editor запускал, там минимальная настройка, он вроде уже на основе готовых исходников код генерирует?

Qsys генерирует handoff. На основании handoff'а bsp-editor генерирует прелоадер.
Прелоадер может быть двух вариантов - spl (secondary preloader) и MPL (minimal preloader). Для MPL как раз HWLib нужен.
Посмотрите подробности по бутингу SoС'ов на rocketboards.org

Интересно!
А MPL поддерживает DDR память или нет?
Он даже может загружать FPGA, чего не умеет полновесный SPL, похоже

Блин, многовато аббревиатур получается - MPL, SPL, U-BOOT, Preloader...
В текстах доков постоянно перемешивают preloader, u-boot и spl

Поддерживает. А вот насчёт загрузки FPGA не уверен, загрузится с FPGA он да должен мочь.


Потому что они почти всегда под этими терминами имеют ввиду u-boot цитата из
https://rocketboards.org/foswiki/view/Docum...Generation_Flow
The Preloader is based on the SPL (Secondary Program Loader), which is a component of U-Boot, the open source bootloader.


Полностью смысла нет, потому как некоторые моменты документированы почти никак, проще распотрошить MPL и там где он делает прыжок на загружаемую прогу добавить свой код.

VBKesha
Спасибо за помощь!

Да, в файлах MPL есть настройка для загрузки образа для FPGA со скрытого или из FAT раздела.
Очень удобно, надо будет попробовать.
Почему такой опции нет в более навороченном прелоадере - не понятно...

Пока сижу читаю доки, до практики ещё не дошёл.

По поводу кэша данных не подскажете - для его правильной работы обязательно включать MMU?
К примеру, чтобы область регистров периферии и FPGA корок не кэшировалась?
По идее, область регистров должна быть некэшируемой по-умолчанию и без всякого MMU...

Ещё у меня непонятка с настройкой портов железного DDR SDRAM контроллера.
В его регистрах есть задание приоритетов и "весов" (weight) для распределения пропускной способности между различными мастерами.

Но как на практике понять, какой номер порта присвоен какому мастеру?
В QSys просто подсоединяются все корки к единственному мосту FPGA->HPS и поди разбери, какие номера портов там получились...

Есть ещё выделенные порты FPGA->SDRAM, но там тоже нет в свойствах никаких номеров портов или каких-то идентификаторов...

С ACP тоже самое - там в доках по нему должны быть назначены определённые ID, и как это сделать\задать в QSys - не ясно.
Наверное, ручками надо допиливать сгенерированные файлы...

Вот тут в разделе "Настройка U-boot" вроде расписано как делать через U-Boot если я правильно понял.


Судя по HWLIB его можно включить/выключить, заинвалидить итд, глубже пока не копался. Для L2 можно назначить фильтр для прямого обращения.


Вроде бы порты имеются ввиду только для прямой работы FPGA<->DDR судя по этой картинке а то что висит FPGA->HPS не имеет к этому отношения.


По многим вопросам можно более менее пытаться более менее понять глядя на HWLIB.

Через U-Boot можно, но я имею ввиду не его, а SPL, то есть preloader. Через него нельзя, там в исходниках об этом ни слухом, ни духом.

Я пока что пользоваться U-Boot не буду, пока с bare-metal буду возиться. А для этого надо только SPL или MPL.
Последний больше нравится.


Да, я нашёл по этому поводу интересный пример, попробую его в первую очередь:

Здесь в простой форме с помощью HWLib создаются необходимые дескрипторы TLB для MMU.

А по поводу фильтра L2 - его регистры, как я понял, определяют нижнюю и верхнюю границы DDR SDRAM области памяти для MPU.
В принципе, возможно, что кэшируется только этот регион памяти, а всё, что в него не входит - автоматически перенаправляется наружу в L3, а не в кэш?
Тогда, для простых приложений, можно просто включать кэш данных, оставив MMU отключенным?


Да, именно эти шесть портов прямого доступа к DDR имеют настройки приоритизации, для распределения полосы между разными мастерами.
Я об этом и говорил.
Quality of Service называется. L3 interconnect тоже имеет подобные настройки.

ЗЫ: не только эти шесть - а все 10 портов (L3 и MPU) приоритизируются:
Нажмите для просмотра прикрепленного файла

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


Да, это точно.
Хорошо, когда есть такая штука.

Примеров бы ещё побольше...
Показалось, что для Zynq в сети больше простых примеров от обычных людей, чем для альтеровских SoC.