[serjj1333 0]

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

 

- Руководствовался инструкцией FPGA Boot 14.0

- Использовался Квартус 14.1 и сопутствующий ему EDS

- Простейший QSys проект для примера для загрузки из FPGA (у меня под плату Arrow SoCkit) QSys

- Перед сборкой preloader лучше удалить папку spl_bsp и сгенерировать заново после первой сборки проекта

- Вот настройки preloader'a 1.txt, которые я использовал

(прим. если не выбран не один пункт загрузки, как в данном примере, 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:

Note that the Preloader is executed directly from the FPGA memory, while the bare-metal is first copied from the SD/MMC to SDRAM then executed.

It is possible to also store the bare-metal application in the FPGA image, but that memory is expensive and its usage should be minimized.

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

 

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

Как я понял, загрузка с флешки самая распространенная пока. Кто как грузился? Кто нибудь пробовал загружать что либо кроме линуха с флешки? Мб кто то пробовал включать поддержку FAT?

 

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

 

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

Изменено 22 января, 2015 пользователем serjj

[WitFed 1]

Эх, лучше бы ты итоговый рецепт загрузки из 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 "архитектурные" К ;) Зато хоть имя файла можно увидеть и глядеть в редакторе.

[vadimuzzz 0]

Как я понял, загрузка с флешки самая распространенная пока. Кто как грузился? Кто нибудь пробовал загружать что либо кроме линуха с флешки? Мб кто то пробовал включать поддержку FAT?

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

[serjj1333 0]

Хочу на отладочной плате (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

[vadimuzzz 0]

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

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

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

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

sockit_ghrd.7z

[serjj1333 0]

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

ALTERA DWMMC: 0
** Partition 1 not valid on device 0 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###

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

[vadimuzzz 0]

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

Disk /dev/sdc: 485,5 MiB, 509083648 bytes, 994304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot  Start    End Sectors Size Id Type
/dev/sdc1       953344 994303   40960  20M  4 FAT16 <32M
/dev/sdc3         2048   4095    2048   1M a2 неизвестный

sdc3 - это раздел с меткой 0xA2, там лежит preloader

sdc1 - раздел с FAT, туда образ бинарника кидаю.

[serjj1333 0]

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

ALTERA DWMMC: 0
reading hwlib-mkimage.bin
reading hwlib-mkimage.bin
SDRAM: Scrubbing success with consuming additional 0 ms

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

image OS = 11
image load address = 1000040
image entry point = 1000040
image size = 32000

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

Как говорится в известном мультфильме: "Ничего не понимаю!" :05:

vadimuzzz, у вас приложение после загрузки образа с fat раздела флеша стартовало само и успешно? Может есть еще какие-то тонкости? :rolleyes:

[serjj1333 0]

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

MKIMAGE := mkimage
$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "baremetal image" -d $(BIN) $(IMG)

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

$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0x100040 -n "baremetal image" -d $(BIN) $(IMG)

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

ALTERA DWMMC: 0
reading hello-mkimage.bin
reading hello-mkimage.bin
image OS = 05
image load address = 100000
image entry point = 100040
image size = 6830
Verifying Checksum ... OK
SDRAM: Scrubbing success with consuming additional 0 ms
Hello!

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

В общем, возможно кому-то будет интересно/полезно :rolleyes: Отпишусь по мере продвижения.

Изменено 2 февраля, 2015 пользователем serjj

[WitFed 1]

Нет, 64 байта первых -- это вектора прерываний.

И самые первые 4 из них есть резетный вектор, который должен привести в то же самое место на смещение 40.

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

[serjj1333 0]

Да, ты прав в случае если это образ preloader'a, из документации:

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

Я делал образ baremetal приложения, у него несколько иная структура:

Действительно 64 байта на хедер.

А хедер расписывается как:

Я думаю эти картинки проилистрируют тему.. :laughing:

[RadiatoR 2]

Всем доброго дня! Решил не создавать новую тему, тем более, что в этой уже опытные люди собрались.

Имеется 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.

 

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

Спасибо большое заранее!

[Burenkov 0]

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

 

2. Каким образом сделать этот самый preloader. Точнее есть ехе-шник bsp-editor с помощью него он создается. Но не понятно откуда берется preloader settings.

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

 

4. Каким образом идет дебаг программы. Вот это не понятно от слова совсем. То есть как идет дебаг в keil понятно - у среды есть исходник, она его зашивает во flash и выполняет. А как здесь не понятно - исходник получается не в среде, точнее он там есть, но запускается код ведь с sd карты. Откуда эклипс знает что там находится?

Я делал по этому видео https://youtu.be/9ieg3KRL0Ow

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

 

 

 

[RadiatoR 2]

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

[Burenkov 0]

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

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