Всем доброго времени суток . Тема является продолжением и развитием FPGA Boot. Собственно на днях вопрос с FPGA Boot потерял актуальность, т.к. загрузиться получилось. Теперь уже не помню, из-за какой настройки preloader не стартовал в этом режиме boot'a, но в итоге получилось собрать так, чтобы заработало. Список необходимого:

- Руководствовался инструкцией FPGA Boot 14.0
- Использовался Квартус 14.1 и сопутствующий ему EDS
- Простейший QSys проект для примера для загрузки из FPGA (у меня под плату Arrow SoCkit) QSys
- Перед сборкой preloader лучше удалить папку spl_bsp и сгенерировать заново после первой сборки проекта
- Вот настройки preloader'a Нажмите для просмотра прикрепленного файла, которые я использовал
(прим. если не выбран не один пункт загрузки, как в данном примере, preloader загружается, выполняется и висит в цикле, не пытаясь что либо делать дальше. при этом можно загружать и отлаживать приложение в SDRAM по JTAG через DS-5 debugger)
- В своем проекте я не завожу резет на FPGA часть, а на HPS Cold reset завожу сигнал, полученный по pll_locked. Как я понял, главное: резет на вход Cold (именно Cold) reset HPS должен прийти после того, как с FPGA части будет снят резет, т.е. FPGA часть будет гарантированно готова к загрузке проца. Мне кажется, что этот пункт меню имеет принципиальное значение.
- Итак, собираем preloader, делаем HEX, все как указано в доке с рокетбордов, подключаем UART к компу, в Putty задаем скорость 115200 бод, заливаем .sof файл и вуаля:
Нажмите для просмотра прикрепленного файла
- profit!

Preloader грузится из OCRAM FPGA, инициализирует DDR3 SDRAM и входит в цикл а-ля for(;;). При этом я могу по JTAG заливать в SDRAM приложение, как hosted так и unhosted (unhosted будет выводить текст в открытое Putty), так что все ок.

Надеюсь, что данная инструкция кому нибудь пригодится. Теперь собственно о текущей проблеме. Хотелось бы пойти дальше и сделать полностью автономную загрузку unhosted baremetal приложения. Preloader копирует код из некоторого хранилища в область SDRAM и передает управление с точки входа Entry point, откуда приложение и начинает выполняться (да простят меня истинные программеры, до этого только rtl дизайном занимался, поэтому может коряво об этом пишу). Сейчас рассматриваю вариант загрузки приложения из другой OCRAM на борту FPGA или из SD-MMC. В дальнейшем хочется загружаться из NAND (на Arrow её просто нет). Вариант с загрузкой приложения из FPGA не является стандартным, т.к. он даже не обозначен в гуи морде bsp-editor при настройке параметров сборки preloader'a. Однако такая возможность есть, т.к. см. Altera Wiki FPGA boot:

Возникает вопрос, как загрузить простейшее приложение из OCRAM FPGA?

Загрузка из SD-MMC предполагает форматирование флешки под какой-то А2 Partition, но при генерации preloader'a есть галочка "поддержка FAT". Как я понял опция как раз для виндовых машин. Ставим поддержку FAT и просто копируем на флешку .img образ приложения, которое хотим запускать. С поддержкой FAT при сборке preloader'a вылазит ошибка Makefile'a:
Нажмите для просмотра прикрепленного файла
Как я понял, загрузка с флешки самая распространенная пока. Кто как грузился? Кто нибудь пробовал загружать что либо кроме линуха с флешки? Мб кто то пробовал включать поддержку FAT?

И еще интересует вопрос, как собственно preloader осуществляет копирование кода приложения в SDRAM и передачу управления на entry point?

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

Эх, лучше бы ты итоговый рецепт загрузки из FPGA точно там же и публиковал, где был блог с Тапянками
Использование OCRAM FPGA для хранения программ -- удовольствие дорогое, ибо они обычно растут большие, а памяти этой немного.
Надо рыть в сторону флэшей сразу же. Ибо они стоят копейки и у всех производителей обычно хранят ПО любой стадии.
Я и тут, и на Альтерном форуме орал на тему "Booting from QSPI flash" более полугода назад, как-то подстругал Прелоадера, чтобы он эмулировал семихостинг через перехват вызова раз 10 "SVC 123456" ещё до main(), -- ибо без соединения с хостом приложения Baremetal тогда просто не компилились у Альтеры.
Летом появился MPL (Minimal Preloader), который обходился без хоста и писал всю консоль в COM-порт, это приложение и нужно пробовать шить сейчас -- Unhosted. Но я не пробовал больше даже, ибо вяло ковыряюсь по другим Штатным мусорникам...
Про "А2 Partition" -- это на вынимаемой флэшине в Partition Table один из разделов должен быть такого самопровозглашенного типа, и там сразу должны лежать 4х64 одинаковых Прелоадеров, а потом кто-то из них, у кого CRC совпадёт, будет запущен и потянет .img из другого FAT-раздела. Там свой формат заголовка, написано, по какому адресу загружать, с какого адреса вход..
Для меня все эти "не-бистрО"-"метОды", плюс Линукс -- непрерывный изврат, но начальство хотело разборок с этой "архитектурой", и Baremetal от Альтеры иже с ним пока демонстрировали не лучший уровень... Вдруг что и поменялось, но рассылки об этом молчат.
По уму, у процессора на 0-м адресе должно торчать любое устройство, из которого возможно чтение, которое намаппит Системный Архитектор, и с этого 0 должно всё стартоваться напрямую, без пинов и прочих УБу[н]тов.
Не загрузилось, регистр "собачий" не успели за полсекунды тронуть, и нет отладчика -- тогда грузится образ с адреса 16М (этот "шаг" на "запасные образы" как раз и можно задавать пинами типа BSEL) от начала адресного пространства, опять нет -- с 32 М, 48 М, потом заворот, а вдруг флэшь исправилась, типа подогрелась... Т.е. должна быть возможность стартовать всей программой за 1 раз и с отладчиком, и нафиг все мудрёные скрипты ! Иниты всех девайсов должны быть в системной библиотеке, ну и примеры их использования. Как только наинитили DDR -- вызываем функцию перескока туда всего приложения...
Плюс DS-5 должен изнутри себя уметь записывать напрямую во флэшь все свои "хитро-форматные" области, а то алгоритм полного процесса запрятан у Альтеры круче зениц ока
Вроде все разные флэши более-менее открыты по документации, и если их может писать-читать консольный flash-programmer, то и DS-5 потянет. И тогда людям доброй воли будет счастье, в отличие от...
Но это лирика... Жить в эту пору прекрасную...

Про "как собственно preloader осуществляет..." можно узнать у самого его -- вставить где-то на старте "while (1) ;", стартовать в железе, подключиться отладчиком, перенести PC и глядеть по F5/F6, но только оптимизатор там граблей наставил по дороге, ибо без него код не лезет в 64 "архитектурные" К Зато хоть имя файла можно увидеть и глядеть в редакторе.

у меня загрузка с microSD. на 0xA2-разделе лежит preloader, на FAT - образ программы (bare-metal)

Хочу на отладочной плате (Arrow) попробовать сделать запуск baremetal приложения из SDMMC с FAT раздела как раз. Preloader грузится с памяти FPGA. Я правильно понимаю, что если поставить в preloader'e поддержку FAT, то можно просто на флешку сбросить файл образа .img, имя которого указано в настройке preloader'a и он его загрузит и запустит при старте?

Пытаюсь сейчас собрать preloader с поддержкой FAT, вылазит ошибка (на картинке вверху скрин soc eds консоли). Суть ошибки - не может найти __sdram_stack_start, __sdram_stack_end, __bss_fat_start, __bss_fat_end, __malloc_fat_start, __malloc_fat_end. vadimuzzz, как у вас проходила сборка с поддержкой FAT? Если вылазили такие ошибки, то как с ними бороться?

ЗЫ: кривизна альтерного решения продолжает поражать, делал сборку с поддержкой загрузки из NAND (пока только сборку), вылазят ошибки makefile. Вот нашёл решение-костыль от Altera, мб кому то будет полезно решение NAND

у меня именно так и сделано. я приложил проект для Arrow SoCKit.

у вас что-то не то с линкером, он пишет про переполнение SRAM.

vadimuzzz, спасибо большое. Вот только все равно не выходит. Вы как флешку форматировали? Я сделал просто быстрое форматирование в FAT со стандартным размером кластера. Потом скинул на нее образ .bin, переименовал его в соответствии с настройками preloader'a, вставил флешку в Arrow. Пробую отлаживать, вначале все норм, preloader грузится, но когда до флеша доходит выскакивает в консоли следующее:

Я так понимаю что то не так с форматированием флеша, правильно?

вот таблица разделов:

sdc3 - это раздел с меткой 0xA2, там лежит preloader
sdc1 - раздел с FAT, туда образ бинарника кидаю.

Получилось загружать образ приложения preloader'ом с флешки с разметкой FAT, вот такой лог вылазит в терминале:

Но код не выполняется, я заливаю простой unhosted Helloworld, semihosting выключен, в консоли должен вылезти printf после прогрузки preloader'a. По аналогии с тем, когда я заливаю образ приложения вручную через дебагер. Начал рыться в исходниках убута, бинарник читается 2 раза: сначала заголовок, в котором описаны размер, тип, куда положить, точка входа, а потом собственно сам файл копируется по означенному адресу. Так я понял во всяком случае. Сделал вывод полей заголовка в терминал на этапе вычитывания с флешки:

Посмотрел, что лежит по адресу 0х01000040, сравнил с образом. Содержимое памяти по данному адресу совпадает с образом, который я скинул на флешку, вроде бы все ок. Но после завершения preloader'a ничего не происходит и процессор висит. Нашёл, что переход от preloader'a к приложению осуществляется в функции jump_to_image_no_args(). Встал брейкпойнтом на последнюю строку - image_entry((u32 *)boot_params_ptr); Дебагер до нее дошел, потом делаю step - все зависает. Если прерываю выполнение, проц висит где-то в районе S:0x004ххххх.
Как говорится в известном мультфильме: "Ничего не понимаю!"
vadimuzzz, у вас приложение после загрузки образа с fat раздела флеша стартовало само и успешно? Может есть еще какие-то тонкости?

Разобрался с запуском приложения! Во первых использовал неправильный бинарник - я брал *.bin, а нужно было *-mkimage.bin, который порождается утилитой mkimage. Во вторых в альтеровском unhosted примере она используется вот таким образом (в Makefile'e):

-e 0 означает, что точка входа = 0х0, я исправил на

Сейчас в консоли вижу следующее:

-a 0x100040 указывает на то, что образ должен загружаться по данному адресу, но в консоли видно, что она грузится по адресу 100000. Тут немного непонятно, наверное 64 байта вначале зарезервированы под заголовок.
В общем, возможно кому-то будет интересно/полезно Отпишусь по мере продвижения.

Нет, 64 байта первых -- это вектора прерываний.
И самые первые 4 из них есть резетный вектор, который должен привести в то же самое место на смещение 40.
Точного и полного "вкусного" описания всех процессов для старта HPS отовсюду я так и не встретил -- будет очень замечательно, если кто-то хоть через 2 года после выпуска этой платформы изложит по-человечески. А то народ периодически страдает...

Да, ты прав в случае если это образ preloader'a, из документации:
Нажмите для просмотра прикрепленного файла
В начале действительно прерывания, а хедер мапируется выше.
Я делал образ baremetal приложения, у него несколько иная структура:
Нажмите для просмотра прикрепленного файла
Действительно 64 байта на хедер.
А хедер расписывается как:
Нажмите для просмотра прикрепленного файла
Я думаю эти картинки проилистрируют тему..

Всем доброго дня! Решил не создавать новую тему, тем более, что в этой уже опытные люди собрались.
Имеется DE0-nano-SOC.
Цель - приложение barametal и отладка по jtag. Из источников кода есть только microSD (FPGA не планирую использовать как источник).

Т.к. ранее имел дело только с AVR/ARM (cortex-m) все было проще простого - магическим образом keil и AVR studio все делали за меня, я только писал исходники, проект загружался во flash и выполнялся оттуда, максимум из внутренней RAM. Здесь все поменялось. Пришлось разгребать. В результате я изучил:
1. Как устроен жесткий диск
2. MBR сектор
3. CHS/LBA
4. Прочитал (не весь) Cyclone V Hard Processor System Technical Reference Manual
5. Прочитал boot гайды по запуску HPS (https://www.altera.com/content/dam/altera-w...re/an/an709.pdf и https://www.altera.com/content/dam/altera-w...v/cv_5400a.pdf)
6. Просмотрел загрузочную флешку, что идет в комплекте к киту через PartitionGuru. Нашел там всё и вся - раздел A2 (кстати, про него пишут тут: https://en.wikipedia.org/wiki/Partition_type) и сам образ оси.
7. Разобрался в составе preloader (вектора прерываний, хидер, код и CRC)
8. Последовательность загрузки системы

Далее (uboot и OS) все в принципе понятно. Не разобрался только в:
1. Как сделать makefile, для чего он нужен и нужно ли его делать самому
2. Каким образом сделать этот самый preloader. Точнее есть ехе-шник bsp-editor с помощью него он создается. Но не понятно откуда берется preloader settings.
3. Как можно написать preloader со своим кодом
4. Каким образом идет дебаг программы. Вот это не понятно от слова совсем. То есть как идет дебаг в keil понятно - у среды есть исходник, она его зашивает во flash и выполняет. А как здесь не понятно - исходник получается не в среде, точнее он там есть, но запускается код ведь с sd карты. Откуда эклипс знает что там находится?
5. И вообще каким образом пишется прога, ведь нужно ее будет залить на флешку. Возможно даже без форматирования, если это raw mode.

В общем не понятны эти моменты. Может кто в двух-трех словах описать как это все дело происходит?
Спасибо большое заранее!

Как раз недавно немного поковырял SOC...


В Qsys нужно зайти в компонент HPS, сделать там необходимые настройки и сгенерить его, и потом собрать проект в квартусе(может и не обязательно, может достаточно только снегерить проект в Qsys). В корне проекта создастся папка hps_handoff, внутри которой и лежат все настройки, bsp-editor по умолчанию берет их оттуда и использует при генерации.


Я делал по этому видео https://youtu.be/9ieg3KRL0Ow
При отладке не обязательно ведь грузить с флешки, можно и программатором загрузить

А программатор куда грузит? В 60кб оперативки и стартует из нее?

Не могу точно сказать щас. На работе в понедельник гляну линкер скрипт. Я думаю что таки в ddr грузит

Но ддр еще не инициализирована. Ее как раз и запускает прелоадер.

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

Как правило отладчик использует простой скрипт, в котором сначала в onchip память грузится прелоадер, запускается, делает всю необходимую инициализацию, а уже затем в DDR SDRAM грузится приложение.

Да, действительно, вы правы. Вот что пишут в самом начале скрипта

# This is an ARM DS5 debugger script that is intended to help folks run and
# debug uboot. It loads the preloader (a.k.a. spl) into onchip ram, runs it
# to setup DDR

Да, так я и думал.
А может кто-нибудь сбросить пример настроенного проекта с прелоадером для de0-nano-soc. Я бьюсь, бьюсь все никак не может заработать. Для arrow kit примеры есть, а для нано не могу найти. Какой-то пример прелоадера нашел в папке, скомпилил, DS-5 видит бластер, вроде все ок, но при попытке дебага пишет:
Starting debug server
Waiting for debug server to start accepting connections
и на этом его можно ждать бесконечно долго, в итоге он не подключится. Такая ситуация у меня с любым проектом. Линукс с флешки работает норм.

Я работаю с DE1-SoC, с de0-nano-soc дела не имел, к сожалению.
Но заметил, что дебаггер не работает, когда частота HPS процессора установлена меньше 100 МГц.
К примеру, задаю в Qsys частоту MPU Clock Frequency на 50 МГц, всё компилируется без ошибок. Но дебаггер (через USB-Blaster) соединиться с платой не может, сыпет ошибками.

PS: а от компилятора как нибудь может зависеть работоспособность дебаггера?
С ARM компилятором он работает, а с GCC кто нибудь пробовал?

да, работает