[VBKesha 0]

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

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

 

Хм. Могли бы хотя бы сделать полной отладкой вместе с BootRom. А то так получается скрипт хз что делает и какими-то путями приводит к main.

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

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

 

 

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

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

 

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

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

[RadiatoR 2]

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

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

[sonycman 0]

А альтеровской HWLib кто нибудь пользуется?

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

 

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

А у Альтеры только ручками...

[sonycman 0]

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

 

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

 

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

 

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

Preloader IOCSR & Pinmuxing Parameters

 

The IOCSR parameters define the HPS pin behavior: input or output, drive strength, logic levels etc.

The file is called iocsr_config_<cyclone/arria>5.h and .c and is generated automatically by the Preloader Generator based on the handoff information from Qsys.

These files cannot be manually edited, since the IOCSR interface is not publicly documented.

 

The pin muxing parameters are stored in the file pinmux_config.h and are generated by the Preloader Generator based on Qsys settings.

They should not be generally edited by hand.

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

Запутался... :blink:

[vadimuzzz 0]

А альтеровской HWLib кто нибудь пользуется?

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

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

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

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

[sonycman 0]

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

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

 

Частоты всех модулей по умолчанию какие получаются?

В настройках GUI прелоадера нет ни слова об этом.

Посмотрел здесь - проц на 800 МГц, и остальные модули расписаны.

Не знаю, совпадает ли с платой DE1-SoC.

[vadimuzzz 0]

Частоты всех модулей по умолчанию какие получаются?

В настройках GUI прелоадера нет ни слова об этом.

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

[sonycman 0]

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

Спасибо, я пока в квартус не заходил даже, после MAX10.

С софтовой частью HPS разбираюсь.

 

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

В силу слабой документации в первую очередь.

 

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

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

[StewartLittle 41]

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

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

Qsys генерирует handoff. На основании handoff'а bsp-editor генерирует прелоадер.

Прелоадер может быть двух вариантов - spl (secondary preloader) и MPL (minimal preloader). Для MPL как раз HWLib нужен.

Посмотрите подробности по бутингу SoС'ов на rocketboards.org

 

[sonycman 0]

Прелоадер может быть двух вариантов - spl (secondary preloader) и MPL (minimal preloader). Для MPL как раз HWLib нужен.

Интересно!

А MPL поддерживает DDR память или нет?

Он даже может загружать FPGA, чего не умеет полновесный SPL, похоже :)

 

Блин, многовато аббревиатур получается - MPL, SPL, U-BOOT, Preloader...

В текстах доков постоянно перемешивают preloader, u-boot и spl :(

 

 

[VBKesha 0]

Интересно!

А MPL поддерживает DDR память или нет?

Он даже может загружать FPGA, чего не умеет полновесный SPL, похоже :)

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

 

Блин, многовато аббревиатур получается - MPL, SPL, U-BOOT, Preloader...

В текстах доков постоянно перемешивают preloader, u-boot и spl :(

Потому что они почти всегда под этими терминами имеют ввиду 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.

 

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

В силу слабой документации в первую очередь.

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

Изменено 1 августа, 2016 пользователем VBKesha

[sonycman 0]

VBKesha

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

 

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

Очень удобно, надо будет попробовать.

Почему такой опции нет в более навороченном прелоадере - не понятно...

 

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

 

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

К примеру, чтобы область регистров периферии и FPGA корок не кэшировалась?

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

 

Ещё у меня непонятка с настройкой портов железного DDR SDRAM контроллера.

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

 

Но как на практике понять, какой номер порта присвоен какому мастеру?

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

 

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

 

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

Наверное, ручками надо допиливать сгенерированные файлы... :(

[VBKesha 0]

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

Очень удобно, надо будет попробовать.

Почему такой опции нет в более навороченном прелоадере - не понятно...

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

 

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

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

К примеру, чтобы область регистров периферии и FPGA корок не кэшировалась?

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

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

 

Ещё у меня непонятка с настройкой портов железного DDR SDRAM контроллера.

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

 

Но как на практике понять, какой номер порта присвоен какому мастеру?

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

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

 

 

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

Изменено 2 августа, 2016 пользователем VBKesha

[sonycman 0]

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

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

 

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

Последний больше нравится.

 

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

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

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include "alt_cache.h" 
#include "alt_mmu.h" 

int __auto_semihosting;

#define N 256
#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))

void mul(const double *in_a, const double *in_b, unsigned n, double *out);

/* MMU Page table - 16KB aligned at 16KB boundary */
static uint32_t __attribute__ ((aligned (0x4000))) alt_pt_storage[4096];

static void *alt_pt_alloc(const size_t size, void *context)
{
return context;
}

static void mmu_init(void)
{
uint32_t *ttb1 = NULL;

/* Populate the page table with sections (1 MiB regions). */
ALT_MMU_MEM_REGION_t regions[] = {
/* Memory area: 1 GiB */
{
.va = (void *)0x00000000,
.pa = (void *)0x00000000,
.size = 0x40000000,
.access = ALT_MMU_AP_FULL_ACCESS,
.attributes = ALT_MMU_ATTR_WBA,
.shareable = ALT_MMU_TTB_S_NON_SHAREABLE,
.execute = ALT_MMU_TTB_XN_DISABLE,
.security = ALT_MMU_TTB_NS_SECURE
},

/* Device area: Everything else */
{
.va = (void *)0x40000000,
.pa = (void *)0x40000000,
.size = 0xc0000000,
.access = ALT_MMU_AP_FULL_ACCESS,
.attributes = ALT_MMU_ATTR_DEVICE_NS,
.shareable = ALT_MMU_TTB_S_NON_SHAREABLE,
.execute = ALT_MMU_TTB_XN_ENABLE,
.security = ALT_MMU_TTB_NS_SECURE
}
};

assert(ALT_E_SUCCESS == alt_mmu_init());
assert(alt_mmu_va_space_storage_required(regions, ARRAY_SIZE(regions)) <= sizeof(alt_pt_storage));
assert(ALT_E_SUCCESS == alt_mmu_va_space_create(&ttb1, regions, ARRAY_SIZE(regions), alt_pt_alloc, alt_pt_storage));
assert(ALT_E_SUCCESS == alt_mmu_va_space_enable(ttb1));
}

int main(int argc, char** argv) {
static double a[N], b[N], c[N];
unsigned i, t;

mmu_init();
alt_cache_system_enable();

for (i = 0; i < N; i++) {
a[i] = (double)rand();
b[i] = (double)rand();
}

*(unsigned volatile *)0xFFFEC600 = 0xFFFFFFFF; /* timer reload value */
*(unsigned volatile *)0xFFFEC604 = 0xFFFFFFFF; /* current timer value */
*(unsigned volatile *)0xFFFEC608 = 0x003; /* start timer at 200MHz and automatically reload */
mul(a, b, N, c);
t = *(unsigned volatile *)0xFFFEC604;
printf("used time for %u multiplications = %u ns\n", N, 5 * (0xFFFFFFFF - t));

return 0;
}

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

 

А по поводу фильтра L2 - его регистры, как я понял, определяют нижнюю и верхнюю границы DDR SDRAM области памяти для MPU.

В принципе, возможно, что кэшируется только этот регион памяти, а всё, что в него не входит - автоматически перенаправляется наружу в L3, а не в кэш?

Тогда, для простых приложений, можно просто включать кэш данных, оставив MMU отключенным?

 

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

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

Я об этом и говорил.

Quality of Service называется. L3 interconnect тоже имеет подобные настройки.

 

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

 

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

 

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

Да, это точно.

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

 

Примеров бы ещё побольше...

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