Cyclone V: загрузука HPS из памяти FPGA (FPGA boot) Опции

[serjj]

Доброго дня. Есть отладочная плата Arrow SoCkit от Terasic. Занимаюсь поднятием HPS, в частности зазгрузкой прелоадера (preloader). Приложения Baremetal. Удалось прогрузить кастомный прелоадер по JTAG через DS-5 Debugger. SDRAM успешно инициализируется/калибруется, в нее загружается приложение, выполняется, вроде бы все ок. Пошел дальше: стоит задача реализовать режим загрузки FPGA Boot, описанный в документации. Руководствовался документом AN709 HPS SoC Boot Guide - Cyclone V SoC Development Kit дока и инструкцией инструкция rocketboards. BSEL выставлен в 0х1 (FPGA boot mode). Сигналы разрешения загрузки из FPGA выставлены по мануалу, но HPS не загружается. Попытался подключиться дебагером, посмотреть что же там происходит: пишет, что проц в состоянии running. Попытки его остановить дают следующую ошибку:

Код

ERROR(TAD9-NAL30):
! Unable to stop device Cortex-A9_0
! Cannot stop target.

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

Также проверил при BSEL 0x0, что по адресу 0xC0000000 (адрес On-Chip RAM в FPGA с hex файлом прелоадера) лежит собственно прелоадер. Возможно, HPS не выгружает прелоадер из памяти FPGA в свою встроенную память после снятия резета или он считывается неправильно. Сталкивался ли кто нибудь с загрузкой из ПЛИС раньше? Может быть какие нибудь идеи, куда копать? С примерами такой загрузки довольно тухло (как впрочем с примерами Baremetal вообще). Буду рад любой помощи!

Прикрепленные файлы

 an709.pdf ( 1.41 мегабайт ) Кол-во скачиваний: 35

 

[serjj]

Обнаружил интересную особенность: поставил в проекте power up trigger в signaltap на сигнал RVALID AXI шины h2f. При чтении по шине, сигнал должен выставляться в 1. Однако при старте этого не происходит, следовательно процессор не считывает код preloader'a во внутреннюю память. При этом, как было отмечено BSEL = 0x1 и сигныл разрешения загрузки из FPGA выставлен в 1. Вопрос знатокам HPS, почему стартовый код проца не инициализирует обмен по шине?
Крайне нужен совет!

Сообщение отредактировал serjj - Dec 29 2014, 15:35

[vadimuzzz]

а FPGA загрузилась?

For direct execution from the FPGA fabric boot source, the boot ROM code waits until the FPGA portion of the
device is in user mode, and is ready to execute code and then passes software control to the preloader in the
FPGA RAM.

[serjj]

Да загрузилась, встают PLL, я параллельно смотрел сигнал reset, который у меня вырабатывается по сигналу pll_locked. Он честно падает после загрузки FPGA. Если я убираю джампер, выставляя BSEL = 0x0, то я могу подключиться к процессору через дебагер и залить туда preloader вручную, так же в этом режиме проверил чтение из памяти FPGA и сигнал RVALID, все нормально читается, так что шина подключена правильно.

ЗЫ:
Еще на одну вещь обратил внимание. При BSEL != 0x0, если в дебаггере подгрузить вручную preloader и посмотреть в Memory viewer содержимое сектора 0c0000000, то все ок, там лежит preloader, который должен загружаться из FPGA, но если запустить в дебаггере проект без preloader'a, то при попытке почитать по адресу 0c0000000 мы увидем, что память недоступна. Разве preloader как то управляет шиной h2f AXI? Получается как будто проц не видит сектор по 0c0000000 изначально и его нужно проинициализировать, но как тогда с загрузкой из FPGA...

Сообщение отредактировал serjj - Dec 30 2014, 07:35

[WitFed]

Мне летом какой-то крутой ARM-перец на форуме Альтеры советовал хитрый метод отладки всего стартапа HPS в DS-5, начиная с 1 команды BootROM, только я забросил всё это болото Альтерное после неисчислимых мучений ёжика в тумане... Сырость неописуемая, и эти ребята во главе с Об. запрещают нам ковыряться пальцем в носу !..

...Там примерно надо было нажать резетную кнопку на плате и держать, в DS-5 как-то подключиться "на будущее", отпустить кнопку -- и отладчик становится на самое начало по адресу 0, потом можно по дизассемблеру степать и видеть место, где висяк -- это глядя из самого проца. Но исходников С-ных нет в принципе, логику и названия функций надо соображать по asm.

Ну и из ПЛИС можно в Тапок вывести чтение того куска ОЗУ, в котором Прелоадер сидит. Хотя бы из окна Memory видна она или висяк моментальный.
Только у Альтеры, как повелось издревле, трудно отлаживать стартовые процессы -- прошивка должна уже сидеть и ждать, только тогда можно пускать Тапка вручную, нет автоматизации с его автостартом, как только прошивка загрузится.
Но проца можно держать в резете и отпускать, только когда Тапок включится.

По идее, увидев BSEL для загрузки из ПЛИС, BootROM должен проинитить мост проц-ПЛИС самостоятельно, у него же незря 60 К кодов заложено на всё про всё в неисчислимых вариантах. И передать управление на содержимое C0000000, которое должно стать видимым.
Вообще, зря они намудрили с этими BSEL-ами и BootROM-ами накристалльными... Самое надёжное и удобное нам решение -- отдать загрузку на откуп системному архитектору (обычно никому не нужны несколько src) и 1-стадийное ПО. Проц стартует с 0, и что ему там подставили на шине по этому адресу на чтение, то пусть и запускается, мудрствование обычно всегда бывает лукавым. Плохой носитель -- можно повторять попытки загрузки с адреса 4М, 8М...
В 4М флэши можно уже уместить нормальное приложение, которое и полный функционал обеспечит, и при необходимости DDR подымет и скопирует свой кусок туда, но только при нормальном отладчике и надёжности.

[serjj]

Автостарт Signaltap сделал, но вот чтения по h2f AXI не происходит после перехода FPGA в User Mode. У меня сигналы boot_from_fpga_ready = 1 и boot_from_fpga_on_failure = 0 заданы жестко константами, может их нужно привязать к резетам? При этом резет на память OCRAM FPGA и на HPS генерируется по pll_locked. Как вариант попробовать задержать сигнал резета для HPS... CLKSEL = 0x0, может это как то влияет?

[serjj]

Новые новости с Boot фронта
После подачи питания и залифки .sof файла удалось получить в signaltap следующие эпюры:



При этом видно, что данные вычитываются из памяти подряд на каждом такте и никак не привязаны к сигналу RVALID. Если я читаю содержимое сектора 0с0000000 вручную, то картинка получается такая:



Транзакция на шине сопровождается сигналом RVALID, по которому master будет капчурить данные, полученные от slave'a. Я пока не специалист по AXI, но по-моему очевидно, что эпюр на второй картинке соответствует правильной транзакции, а на первой - неправильной. Уже хорошо то, что проц пытается что-то прочитать после загрузки FPGA , но вопрос почему он считывает данные неправильно?..

PS. Сейчас все резеты сняты по умолчанию при загрузке FPGA:

Код

        .reset_reset_n                                ( 1'b1 ),
        .hps_boot_fpga_boot_from_fpga_ready            ( 1'b1 ),
        .hps_boot_fpga_boot_from_fpga_on_failure    ( 1'b0 ),
        .hps_cold_rst_reset_n                        ( 1'b1 ),
        .hps_debug_rst_reset_n                        ( 1'b1 ),
        .hps_warm_rst_reset_n                        ( 1'b1 ),

Если подавать резеты, сформированные по pll_locked, то проц не пытается загружаться с FPGA

[vadimuzzz]

ые по pll_locked, то проц не пытается загружаться с FPGA

заведите все эти ресеты и прочую шелуху в сигналтап. хочется посмотреть именно на момент перехода fpga в user mode

[serjj]

При старте FPGA получается следующая картинка:

Резет для процессора я специально задержал, что бы он начал грузиться чуть позже. На эпюре фактические резеты с процессора и памяти сняты, как я писал выше. Пробовал вместо этого заводить сигналы reset и reset_hps_n, с ними проц не начинал вычитывать preloader.

[vadimuzzz]

а можно все эти сигналы в кучу собрать (axi полностью и ресеты)? у меня есть подозрение, что обе эпюры транзакций по axi правильные, только типы burst разные. кстати, а что лежит в ocram со стороны fpga?

[alexPec]

Автору большая просьба: опишите поподробней правильную последовательность действий, чтобы все это заработало и в чем были проблемы. Скоро собираюсь тоже заняться циклоном 5 и его HPS. Думаю на эти грабли многие наступают и было бы полезно выложить максимум информации по проблеме.

[serjj]

2 vadimuzzz, в OCRAM лежит hex preloader'а, формат слова - 8 бит, как указано в рекомендации Altera для FPGA boot. Как до работы доберусь, еще раз все посмотрю и сделаю эпюры полностью по шине AXI.

2 alexPec, рекомендации по FPGA boot mode я привел в начале темы, там линк на сайт рокетбордов и доку Altera. Для загрузки по JTAG могу привести пример как у меня заработала SDRAM и собственно стартовала программа из нее, если нужно. Мысли только в кучу собиру, что бы по существу написать )

[Jury093]

Сталкивался ли кто нибудь с загрузкой из ПЛИС раньше? Может быть какие нибудь идеи, куда копать? С примерами такой загрузки довольно тухло (как впрочем с примерами Baremetal вообще). Буду рад любой помощи!

попробуйте пройти по заведомо рабочей траектории:
http://habrahabr.ru/post/235707/
с учетом специфики своего железа..
а уж потом запилите свое baremetal..

[serjj]

Продолжение "войны" с 5-м Cyclone'ом
Пост на хабре я читал, всё конечно здорово, но вопрос не в Baremetal или Linux, а в загрузке HPS из FPGA. Сделал снимок каналов AXI Address Read и Data Read в Signaltap. И вот что получилось:



Поставил триггер на ARVALID. Он ставит начальный адрес бёрста, адрес текущий до памяти доходит, данные вычитываются, но сигналы RVALID и RREADY на канале Data Read не выставляются, следовательно мастер (HPS) не получает данные. За согласование интерефейсов памяти и проца отвечает компонент mm_interconnect, который qsys поставил сам. Это первый момент, который меня смутил. Второй: адрес выставляется не по порядку, но тут я не уверен - может так и надо, порядок вычитывания определяет программа Boot loader'a, которая зашита в ROM HPS и недоступна... А вот таже картинка, только в другом масштабе, сигналы RVALID & RREADY так и не появляются.



Документ по AXI, по которому смотрю как и что должно быть, может кому будет полезно
 AXI4_specification.pdf ( 1.82 мегабайт ) Кол-во скачиваний: 557


ЗЫ: может кто поделиться лекарством для DS-5? пробная лицензия закончилась...

Сообщение отредактировал serjj - Jan 12 2015, 09:44

[alexPec]

Добрый день, serjj.

Появилось время на знакомство с HPS, появились вопросы, которые Вы видимо прошли. Если не трудно помогите советом.

1. Почему boot из FPGA? Надо же что-то в FPGA городить чтобы залить файл в HPS? Хочу использовать boot из QSPI (FPGA и HPS), может чего-то не учел?
2. В DS5 как создается проект? Просто new project c++ и все, пишем сорс, компилируем и готово? Привык что в ниосе еще огромная BSP. Неужели тут ничего, кроме сорсов приложения ?
3. При boot-е из QSPI я так понял сначала грузим HPS, а как грузится FPGA? Видел что надо rbf файл сделать, а куда его втолкнуть потом?

Пока в голове каша, может вопросы примитивные, пожалуйста подскажите документы в которых искать ответы.


Спасибо.

[serjj]

Здравствуйте.

Почему boot из FPGA? Надо же что-то в FPGA городить чтобы залить файл в HPS? Хочу использовать boot из QSPI (FPGA и HPS), может чего-то не учел?

Потому что на нашей плате есть только Cyclone V и NAND flash. По задумке preloader грузится из FPGA OCRAM, а приложение - из NAND. Тип приложения - baremetal. При это ПЛИС умеет грузить себя сама.

В DS5 как создается проект? Просто new project c++ и все, пишем сорс, компилируем и готово? Привык что в ниосе еще огромная BSP. Неужели тут ничего, кроме сорсов приложения ?

Советую для начала брать за основу проекты вот отсюда. Мне помогает. Там не все так просто, нужно правильно настроить makefile, я вот например раньше его открывал, только что бы настройки bsp подкорректировать, с SoC нужно будет чаще туда лазить.. Использую gcc для сборки. Вот пару советов:
- запускайте Eclipse через EDS консоль, тогда он правильно подхватывает все зависимости, иначе могут быть ошибки на этапе сборки проектов
- в папке ALTERA_PATH\VERSION\embedded\ip\altera\hps\altera_hps\hwlib\include лежат h-шники альтеры, которые понадобяться для работы с периферией проца
- для подключения новой периферии его нужно добавить 1) в инклуде исходника, 2) в makefile, пример:
В С файле код, который останавливает Watchdog:

Код

#include <stdio.h>
#include "alt_clock_manager.h"
#include "alt_watchdog.h"
int main(int argc, char** argv) {
    ALT_STATUS_CODE status = ALT_E_SUCCESS;
    if (status == ALT_E_SUCCESS)
    {
        printf("INFO: Stopping Watchdog 0 Timer.\n");
        status = alt_wdog_stop(ALT_WDOG0);
    }
    // Check if Watchdog0 is running
    if (status == ALT_E_SUCCESS)
    {
        if (alt_wdog_tmr_is_enabled(ALT_WDOG0) == true)
        {
            printf("INFO: Watchdog 0 Timer is running.\n");
        }
        else
        {
            printf("INFO: Watchdog 0 Timer is not running.\n");
        }
    }
    printf("Hello!\n");
    return 0;
}

В Makefile строки, которые отвечают за подключение либ:

Код

HWLIBS_SRC  := alt_watchdog.c alt_clock_manager.c
EXAMPLE_SRC := hello.c io.c
C_SRC       := $(EXAMPLE_SRC) $(HWLIBS_SRC)

За недостатком документации по программированию этого чуда, комментарии в h-шниках весьма полезны для изучения программной модели, там например иногда английским по белому пишут, какие функции нужно вызывать вначале, что бы данная периферия заработала или как что включать/выключать...
- приложение можно собрать либо как hosted либо как unhosted с помощью (как я понял следующих строк Makefile):
Для unhosted:

Код

LINKER_SCRIPT := cycloneV-dk-ram-modified.ld

Для hosted:

Код

LINKER_SCRIPT := cycloneV-dk-ram-hosted.ld

В примерах Altera делается инициализация системы, на нее стоит обратить внимание, особенно на прерывания и MMU. Есть такие чудо файлы - alt_pt.h и alt_pt.c, в альтеровской папке я их не нашел, забрал из примеров, они нужны для инициализации кэша (по-умолчанию он выключен из-за чего проц работает ужасно медленно, разумеется).
Все вышесказанное имеет значение, если вы хотите делать baremetal app. Если у вас линух предполагается, то он всю эту низкоуровневую мишуру сам сделает.. Но нам пока линух неинтересен, поэтому я вожусь с baremetal.

При boot-е из QSPI я так понял сначала грузим HPS, а как грузится FPGA? Видел что надо rbf файл сделать, а куда его втолкнуть потом?

Посмотрите вот отсюда например. Сам не делал, поэтому тут не скажу. Знаю, что rbf размещают в некоторой области флехи, откуда загрузчик его потом заберет. Если хотите порыть вглубь, то вот направление:
в папке, которая создается после генерации preloader'a из которой он потом собирается spl_bps\uboot-socfpga\arch\arm\cpu\armv7\socfpga есть файл spl.c, собственно исходники preloader'a (часть), в конце файла есть секция CONFIG_SPL_FPGA_LOAD, там описана загрузка ПЛИС процом. В preloader'e соответственно нужно эту опцию разрешить.

Удачи.

[alexPec]

Спасибо, очень полезная информация, копаю дальше...

[sonycman]

В примерах Altera делается инициализация системы, на нее стоит обратить внимание, особенно на прерывания и MMU. Есть такие чудо файлы - alt_pt.h и alt_pt.c, в альтеровской папке я их не нашел, забрал из примеров, они нужны для инициализации кэша (по-умолчанию он выключен из-за чего проц работает ужасно медленно, разумеется).

Сейчас уже есть в HWlib файлы alt_cache.h и alt_mmu.h.
В первом есть необходимая настройка кэшей, а во втором - MMU.

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

Кто нибудь работал с кэшами и MMU под bare metal?