Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Сколько памяти нужно для Microblaze
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Страницы: 1, 2
artix
Доброго времени суток, уважаемые форумчане! Есть у нас в конторе штук несколько плат с Spartan6 LX150T на борту, которые уйдут на списание и демонтаж. Но я немного подумав решил, а не сварганить ли на них реальные имитаторы для тестирования железа которое мы делаем. Решил по-ходу разобраться с микроблейзом. Видится следующая структура: микроблейз с езернетом на котором крутится самый простенький веб брозер, с "мордой", на которой можно в соответствующих полях ставить/снимать галки, которые как-бы для пользователя представляют соответствующие поля регистра управления конкретным имитатором , который висит на шине проца и является уже написанной сущностью имитаторы взаимодействують с внешним миром через 485-й рс. Вроде простая система, но возникает следующий вопрос: возможно ли реализовать поставленные задачи , если доступна только RAM, которая есть на кристалле. Ибо никакой внешней ОЗУшки при проектировании данной борды не было предусмотрено.

Спасибо за ответы.

Удачи artix!
_4afc_
У Microblaze нет привязанности к расположению памяти.
Если у вас код "вебброзер с мордой" влезет в отведённые BRAM - то нет проблем.


artix
Цитата(_4afc_ @ Jan 9 2014, 14:05) *
У Microblaze нет привязанности к расположению памяти.
Если у вас код "вебброзер с мордой" влезет в отведённые BRAM - то нет проблем.


Так вопрос собственно в том и заключается: а влезет ли?
Я с такими весчами сталкиваюсь впервые поэтому оценить оч. сложно. Стоит ли заморачиваться? laughing.gif

Спасибо!

Удачи, artix!
Golikov A.
LwIP на спартане 6 не влазит в брамовую память микроблайза в дефолтном своем состоянии, может если его сильно порезать... Микроблайз до 64К макс под память программ и данных вешает, это как бы память на борту, которая делается и грузиться сама. Все остальные брамы можно собирать в память, но это уже внешняя память, и к ней придется писать загрузчик чтобы из нее работать и так далее...

Вообщем легко и не принужденно не выйдет.
artix
Цитата(Golikov A. @ Jan 9 2014, 15:32) *
LwIP на спартане 6 не влазит в брамовую память микроблайза в дефолтном своем состоянии, может если его сильно порезать... Микроблайз до 64К макс под память программ и данных вешает, это как бы память на борту, которая делается и грузиться сама. Все остальные брамы можно собирать в память, но это уже внешняя память, и к ней придется писать загрузчик чтобы из нее работать и так далее...

Вообщем легко и не принужденно не выйдет.


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

_4afc_
Цитата(Golikov A. @ Jan 9 2014, 15:32) *
Микроблайз до 64К макс под память программ и данных вешает, это как бы память на борту, которая делается и грузиться сама. Все остальные брамы можно собирать в память, но это уже внешняя память, и к ней придется писать загрузчик чтобы из нее работать и так далее...


А вот в теме How to use larger BRAM in a MicroBlaze project? народ уверяет, что и по 300кб памяти в брамах пользует, без дополнительного загрузчика...
Я правда пока сей способ не проверял.

А по адресу AR# 52063 14.2 - XPS - How can I increase the Spartan-6 Block RAM to 128K даже пример лежит.
artix
2 _4afc_
Спасибо большое за ссылки!!!!
Дварфик
Ещё одно место где можно поискать лишней памяти -- это микросхема загрузки FPGA. Только вот, это FLASH, а не ОЗУ.
aabmail
Цитата(artix @ Jan 10 2014, 10:38) *
2 _4afc_
микроблейз с езернетом на котором крутится самый простенький веб брозер, с "мордой", на которой можно в соответствующих полях ставить/снимать галки, которые как-бы для пользователя представляют соответствующие поля регистра управления конкретным имитатором , который висит на шине проца и является уже написанной сущностью имитаторы взаимодействують с внешним миром через 485-й рс. Вроде простая система, но возникает следующий вопрос: возможно ли реализовать поставленные задачи , если доступна только RAM, которая есть на кристалле. Ибо никакой внешней ОЗУшки при проектировании данной борды не было предусмотрено.


Artix, позвольте поинтересоваться, а вам удалось это сделать?
Если да, то сколько килобайт брамов у Вас на это дело ушло?

Заранее благодарен.
xor.kruger
Не для холивара, но все же осмелюсь спросить: а зачем вообще писать загрузчик чтобы обращаться к BRAM'ке, бред какой-то sm.gif
По теме - 4,824 КБ (именно такой объем у LX150T) хватит с головой и даже больше.
Golikov A.
потому что в дефолтном состоянии памяти у микроблайза в которую можно программу и данные положить 64К максимум. Это той что получается сама без лишних телодвижений, все сверх через доп пляски.
aabmail
Цитата(xor.kruger @ Jan 21 2014, 15:28) *
Не для холивара, но все же осмелюсь спросить: а зачем вообще писать загрузчик чтобы обращаться к BRAM'ке, бред какой-то sm.gif
По теме - 4,824 КБ (именно такой объем у LX150T) хватит с головой и даже больше.



4,824 КБит = около 600 кБайт - этого может и не хватить. К примеру, если в SDK 14.5 c помощью визарда сгенерить lwIP-приложение, то оно займет около 800 кБайт. Там конечно есть, что урезать. У меня похожая задача уместиться в 380 кБайт LX75T, реализовав TCP.
Corvus
В принципе, уложиться в BRAM можно (есть такой печальный опыт) smile3046.gif , но считать придётся каждый байт и очень много плясать с бубном. Внешняя память очень сильно уменьшит время разработки и увеличит возможности.
xor.kruger
Цитата
потому что в дефолтном состоянии памяти у микроблайза в которую можно программу и данные положить 64К максимум. Это той что получается сама без лишних телодвижений, все сверх через доп пляски.

Скармливал брам-контроллеру 256КБайт - отлично разводит. Сейчас проект под рукой - 128 КБайт - все отлично линкуется и работает.
На худой конец даже если по каким-то причинам "не влазит-не работает-не хочет" можно дополнительно повесить еще брам-контроллер навесить на него блочную память, а в скриптах линковки дописать нужные секции и нужным адресам. Кстати блочную память можно и с под GNU/Linux использовать, предварительно включив в ядре опцию CONFIG_SRAM и описав в dts что-то типа:

Код
sram: sram@5c000000 {
    compatible = "mmio-sram";
    reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
};

Golikov A.
Цитата(xor.kruger @ Jan 23 2014, 14:28) *
Скармливал брам-контроллеру 256КБайт - отлично разводит. Сейчас проект под рукой - 128 КБайт - все отлично линкуется и работает.
На худой конец даже если по каким-то причинам "не влазит-не работает-не хочет" можно дополнительно повесить еще брам-контроллер навесить на него блочную память, а в скриптах линковки дописать нужные секции и нужным адресам. Кстати блочную память можно и с под GNU/Linux использовать, предварительно включив в ядре опцию CONFIG_SRAM и описав в dts что-то типа:

Код
sram: sram@5c000000 {
    compatible = "mmio-sram";
    reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
};


а я чет бился бился, 64 и все... надо будет ручками потом покрутить,
xor.kruger
Код
а я чет бился бился, 64 и все... надо будет ручками потом покрутить,

Я в старых версиях EDK и SDK раньше долго боролся с проблемами которые связаны с генерацией файлов автоматически (тобиж индусскими скриптами). Сейчас использую 14.6 - но проблемы еще есть. Там где можно описать файлы самому ручками - пытаюсь описывать sm.gif У Вас какая версия?
aabmail
У меня сегодня получилось в EDK14.5:
1. Для Спартан-6 добавить 3 брам-контроллера, каждый максимум на 64 кБайт. Больше не дает.
2. Для Кинтекс-7 добавить много брам контроллеров, каждый максимум на 128 кБайт. Больше не дает.

При этом в линкер-скрипте можно объединять брам-контроллеры в общую память и размещать в ней сегменты elf-файла как угодно. Поэтому, как я понял, нет смысла пытаться увеличивать память в одном брам-контроллере.
Привожу пример с объединением двух контроллеров в линкер-скрипте.
Код
MEMORY
{
   microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x0001FFB0
   /*axi_bram_ctrl_0_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00020000
   axi_bram_ctrl_1_S_AXI_BASEADDR : ORIGIN = 0x41440000, LENGTH = 0x00020000
   axi_bram_ctrl_2_S_AXI_BASEADDR : ORIGIN = 0x41460000, LENGTH = 0x00020000*/
   axi_bram_ctrl_a_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00060000
}
Golikov A.
у меня 14.4 ваще... я не модныйsm.gif... вот потому наверное и упираюсь в 64 К.

про объединение в линкере, у вас 3 области которая идет одна за другой.

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

получится что все секции надо руками раскладывать, а большая все равно не влезет?
_4afc_
Цитата(Golikov A. @ Jan 23 2014, 20:29) *
про объединение в линкере, у вас 3 области которая идет одна за другой.
А когда вы просите какую-то секцию положить в область, вы ей какое имя секции указываете?
получится что все секции надо руками раскладывать, а большая все равно не влезет?


Насколько я понимаю секции могут быть в axi_bram_ctrl_a_S_AXI_BASEADDR длиной 0x00060000.

А что за проблема с раскладыванием руками? Мне в проекте где есть DDR постоянно приходится все секции после визарда
перекидывать из DDR в BRAM.
aabmail
Цитата(Golikov A. @ Jan 23 2014, 21:29) *
у меня 14.4 ваще... я не модныйsm.gif... вот потому наверное и упираюсь в 64 К.

про объединение в линкере, у вас 3 области которая идет одна за другой.

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

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


В качестве ответа прикладываю линкер-скрипт целиком.
В общем случае для всех сегментов elf-файла нужно указать один и тот же memory region.
xor.kruger
Цитата
у меня 14.4 ваще... я не модный... вот потому наверное и упираюсь в 64 К.

Размер брамки зависит реально не от версии ISE/EDK и скриптов которые чекают размер перед этапом синтеза (EDK), а от самого кристалла (как в нем расположена памяти) потому что имеется проблема обеспечить одинаковое время доступа ко всем регионам.
На Virtex6 (xc6vlx240t) максимальный размер блочной памяти подключаемый к брам контроллеру составляет 256 K.
Golikov A.
Цитата(aabmail @ Jan 24 2014, 13:36) *
В качестве ответа прикладываю линкер-скрипт целиком.
В общем случае для всех сегментов elf-файла нужно указать один и тот же memory region.


понятно, когда один большой кусок то вопросы снимаются... и че я думал что так низя, это здорово все упрощает,
aabmail
Уважаемые коллеги!
Всем, кого интересует этот вопрос, спешу сообщить, что вариант с объединением нескольких контроллеров памяти в linker-скрипте тупиковый.
ELF хоть и создается, elfcheck хоть и проходит, а вот data2mem ругается ((.

Так что тема использования дополнительных BRAM по-прежнему актуальна.

Цитата(aabmail @ Jan 23 2014, 20:04) *
Привожу пример с объединением двух контроллеров в линкер-скрипте.
Код
MEMORY
{
   microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x0001FFB0
   /*axi_bram_ctrl_0_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00020000
   axi_bram_ctrl_1_S_AXI_BASEADDR : ORIGIN = 0x41440000, LENGTH = 0x00020000
   axi_bram_ctrl_2_S_AXI_BASEADDR : ORIGIN = 0x41460000, LENGTH = 0x00020000*/
   axi_bram_ctrl_a_S_AXI_BASEADDR : ORIGIN = 0x41420000, LENGTH = 0x00060000
}

misyachniy
У меня есть схожий вопрос, задам здесь.
Текст программы рос, рос и вырос.
Теперь не помещается в сегмент ".text".
Попробовал все сегменты перегнать в отдельный контроллер BRAM.
Все равно, не достаточно места.
Порезал "ненужные" функции, программа работает со сбоями.
Есть подозрение, что стек наползает на код или данные.

Каким образом перекинуть часть функций из секции ".text"?
Может еще какие либо секции программ разместить в основном контроллере BRAM?
С точки зрения быстродействия или еще по каим либо соображениям?
aabmail
Я бы посоветовал следующее:

1. Создать еще хотя бы один брам-контроллер (Если, конечно, есть "лишние" BRAMы). Разместить в нем .stack и .heap.
2. Увеличить размер стека. Скорее всего из-за этого и сбоит прграмма.
3. Секции .init и .fini также разместить в _d_bram_ctrl.

Цитата(misyachniy @ Feb 16 2014, 21:27) *
У меня есть схожий вопрос, задам здесь.
Текст программы рос, рос и вырос.
Теперь не помещается в сегмент ".text".
Попробовал все сегменты перегнать в отдельный контроллер BRAM.
Все равно, не достаточно места.
Порезал "ненужные" функции, программа работает со сбоями.
Есть подозрение, что стек наползает на код или данные.

Каким образом перекинуть часть функций из секции ".text"?
Может еще какие либо секции программ разместить в основном контроллере BRAM?
С точки зрения быстродействия или еще по каим либо соображениям?

misyachniy
Цитата(aabmail @ Feb 17 2014, 00:19) *
Я бы посоветовал следующее:

1. Создать еще хотя бы один брам-контроллер (Если, конечно, есть "лишние" BRAMы). Разместить в нем .stack и .heap.
2. Увеличить размер стека. Скорее всего из-за этого и сбоит прграмма.
3. Секции .init и .fini также разместить в _d_bram_ctrl.



В том то и вопрос, что секция ".text" больше чем 64К.
Код нужно разделить на две части.
Я то догадываюсь, что нужно директива pragma, но не нашел конкретного ответа.
Пробовал d_bram_ctrl объявить побольше, но для Spartan6 размер для одного контроллера ограничен в 64К
aabmail
Выделить более 64 кБайт для программы microBlaze возможно. Чтобы это сделать, нужно

1. Добавить новые BRAM-controllers на шины LMB (а не на AXI).
2. Generate bitstream. Отредактировать system_bd.bmm: добавить ADDRESS_RANGEs, как написано в UG658 в гл. Combined address spaces.
3. Export to SKD. Заменить в linker script два bram-контроллера на один контроллер двойного размера. Расположить в нем все сегменты elf. ProgramFPGA. Enjoy.
4. Зафиксировать в UCF расположение BRAM, чтобы не приходилось всякий раз редактировать BMM.


pepelats
Здравствуйте,

Скажете, сколько может весить самая простая программа для Microblaze в релизе и с оптимизацией. Например программа уровня Hello World. Схема при этом самая минимальная.
У меня получается ~14 кбайт. Это нормально? Можно как то уменьшить эти показатели?
Golikov A.
как только вы используете что-то типа printf сразу подключается библиотека, и программа пухнет.
Если вы напишите программу, которая положит данные в буфер UART сама, то будет значительно меньше.
А с библиотеками это нормально...

П.С. В большинстве драйверов от ксалинкс по умолчанию отладка идет через pritf и им подобные, так что проверяйти их исходники, благо они доступны. И еще есть функция xil_printf или как то так, она не подтягивает за собой полную библиотеку, с ней программа поменьше...
pepelats
Цитата(Golikov A. @ Apr 1 2014, 13:09) *
как только вы используете что-то типа printf сразу подключается библиотека, и программа пухнет.
Если вы напишите программу, которая положит данные в буфер UART сама, то будет значительно меньше.
А с библиотеками это нормально...

П.С. В большинстве драйверов от ксалинкс по умолчанию отладка идет через pritf и им подобные, так что проверяйти их исходники, благо они доступны. И еще есть функция xil_printf или как то так, она не подтягивает за собой полную библиотеку, с ней программа поменьше...


да, забыл указать что не использую при этом printf и даже xil_printf. Использую print который вообще вроде как занимает копейки по сравнению с printf.

Код
Function Size Limitations
-------------- ------- ------------------
printf() 51788 None, full featured
iprintf() 18294 No floating point, reentrant
xil_printf() 2953 No floating point, not reentrant(single thread only), no longlong(64 bit)
putnum() 284 Integer to HEX only, no other formats
print() 185 No numbers output, just strings

All of these functions can be prototyped by including <stdio.h>.


Программа Hello World создается из визарда в SDK. И выглядит так:

Код
#include <stdio.h>
#include "platform.h"

void print(char *str);

int main()
{
    init_platform();

    print("Hello World\n\r");

    return 0;
}


и вот это у меня вытягивает на 14 кбайт
aabmail
В таких случаях неплохо создать и посмотреть MAP-файл.

http://electronix.ru/forum/index.php?s=&am...t&p=1244345
pepelats
Цитата(aabmail @ Apr 1 2014, 14:50) *
В таких случаях неплохо создать и посмотреть MAP-файл.

http://electronix.ru/forum/index.php?s=&am...t&p=1244345


Да, спасибо! Действительно помогло. Обнаружил где затесался malloc, который съел кучу памяти и еще по мелочам. Еще добавил ключи которые советовали, убрал все xil_printf. В итоге вместо 160 кбайт получилось 48 кбайт. Интересно, можно еще как то сократить?

Нажмите для просмотра прикрепленного файла
Golikov A.
чет 48 КБайт много, точно столько? на hello world?
много....

можно выкинуть текст исходников от дебага, если это ваши ключики еще не сделали... и так далее... меньше должно быть у меня первые проекты в 16 кБайтовый брам влазили
dm.pogrebnoy
Да там похоже драйвера от периферии подцепились. Или нет?
Golikov A.
думаю тут где то нолик лишний, или в линкере чего-то начудили и какие то спец секции сделали....
aabmail
Цитата(pepelats @ Apr 1 2014, 14:57) *
В итоге вместо 160 кбайт получилось 48 кбайт. Интересно, можно еще как то сократить?


Интересно, какой сегмент больше всех занимает. Можно через XMD посмотреть, или через плагин для totalcmd. Хотя в .MAP видно, что по крайней мере в elf включено fifo. Значит делаются вызовы из соответствующих библиотек.
pepelats
Цитата(Golikov A. @ Apr 1 2014, 18:52) *
чет 48 КБайт много, точно столько? на hello world?
много....


Сорри, что не предупредил. То что я выложил уже не Hello World, т.к. подумал, что даже если его и уменьшу, реально мало мне о чем скажет, поэтому взял свой реальный проект.
В проекте используется AXI Memory Mapped FIFO на примем и передачу. Работаю с ней по прерыванию. Данные получаю с Aurora, отправляю тоже через нее.
Суть программы в получении пакета, его разбора и отправке пакета ответа. Больше кода там пока как раз в работе с FIFO, т.к. обмен происходит через AXI Lite по описанному в примере от Xilinx алгоритму.

Цитата(Golikov A. @ Apr 1 2014, 18:52) *
можно выкинуть текст исходников от дебага, если это ваши ключики еще не сделали... и так далее... меньше должно быть у меня первые проекты в 16 кБайтовый брам влазили


Если имеется в виду версия Debug и Release, то сейчас у меня 48 кбайт в Release варианте. Если что то еще можно дебажное сократить, было бы здорово.

Вообще как думаете, реально подобный софт вместить в 4 кбайта или самый край 8 кбайт? С учетом что сейчас у меня не все реализовано в программе. Необходимо будет добавить алгоритмы работы по SPI, для конфигурирования периферии данными полученными "сверху".

Цитата(aabmail @ Apr 1 2014, 22:39) *
Интересно, какой сегмент больше всех занимает. Можно через XMD посмотреть, или через плагин для totalcmd. Хотя в .MAP видно, что по крайней мере в elf включено fifo. Значит делаются вызовы из соответствующих библиотек.


Вот что при сборке выводится:
Код
Invoking: MicroBlaze Print Size
mb-size dummy_hi_unit.elf  |tee "dummy_hi_unit.elf.size"
   text       data        bss        dec        hex    filename
   8532        336       3404      12272       2ff0    dummy_hi_unit.elf
Finished building: dummy_hi_unit.elf.size


Тут как раз возникает еще вопрос. Получается, что в сумме секции дают 12272. Это вообще откуда? Почему реально там файл 48869 ?

P.S. Да вызовы из библиотек делаются. Как раз по работе с FIFO больше всего.

Еще вот смог получить инфу:

Код
readelf --sections ./dummy_hi_unit.elf

Имеется 27 заголовков раздела, начиная со смещения 0xa9bc:

Заголовки разделов:
  [Нм] Имя               Тип             Адрес    Смещ   Разм   ES Флг Сс Инф Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .vectors.reset    PROGBITS        00000000 000094 000008 00  AX  0   0  4
  [ 2] .vectors.sw_excep PROGBITS        00000008 00009c 000008 00  AX  0   0  4
  [ 3] .vectors.interrup PROGBITS        00000010 0000a4 000008 00  AX  0   0  4
  [ 4] .vectors.hw_excep PROGBITS        00000020 0000b4 000008 00  AX  0   0  4
  [ 5] .text             PROGBITS        a8000000 0000bc 001cac 00 WAX  0   0  4
  [ 6] .init             PROGBITS        a8001cac 001d68 000034 00  AX  0   0  4
  [ 7] .fini             PROGBITS        a8001ce0 001d9c 00001c 00  AX  0   0  4
  [ 8] .ctors            PROGBITS        a8001cfc 001db8 000008 00  WA  0   0  4
  [ 9] .dtors            PROGBITS        a8001d04 001dc0 000008 00  WA  0   0  4
  [10] .rodata           PROGBITS        a8001d0c 001dc8 000438 00   A  0   0  4
  [11] .sdata2           NOBITS          a8002144 002200 000004 00  WA  0   0  1
  [12] .data             PROGBITS        a8002148 002200 000140 00  WA  0   0  4
  [13] .bss              NOBITS          a8002288 002340 000544 00  WA  0   0  4
  [14] .heap             NOBITS          a80027cc 002340 000404 00  WA  0   0  1
  [15] .stack            NOBITS          a8002bd0 002340 000400 00  WA  0   0  1
  [16] .debug_line       PROGBITS        00000000 002340 001e9f 00      0   0  1
  [17] .debug_info       PROGBITS        00000000 0041df 0028b0 00      0   0  1
  [18] .debug_abbrev     PROGBITS        00000000 006a8f 000fba 00      0   0  1
  [19] .debug_aranges    PROGBITS        00000000 007a50 0002f8 00      0   0  8
  [20] .debug_frame      PROGBITS        00000000 007d48 000520 00      0   0  4
  [21] .debug_loc        PROGBITS        00000000 008268 001728 00      0   0  1
  [22] .debug_ranges     PROGBITS        00000000 009990 000348 00      0   0  1
  [23] .debug_str        PROGBITS        00000000 009cd8 000bcb 01  MS  0   0  1
  [24] .shstrtab         STRTAB          00000000 00a8a3 000117 00      0   0  1
  [25] .symtab           SYMTAB          00000000 00adf4 000990 10     26  42  4
  [26] .strtab           STRTAB          00000000 00b784 000761 00      0   0  1
Обозначения флагов:
  W (запись), A (назнач), X (исполняемый), M (слияние), S (строки),
  I (инфо), L (порядок ссылок), G (группа), T (TLS), E (исключён), x (неизв.)
  O (треб. доп. обработка ОС) o (специфич. для ОС), p (специф. для процессора)

интересно что за секции .debug_* и можно ли их как то порезать.
Golikov A.
погодите погодите!
у вас размер программки 12 КБ, а откуда вы берете цифру 48? Если в измеряете выходной файл что в ПЛИС заливается, то 1 он в АСКИ формате а не бинарь, то есть все данные побиты на пакеты, снабжены контрольной суммой, заголовком и адресами. Каждый байт представлен двумя и кроме прошивки содержит еще сам проц, конфигурацию железа.


Секции дебуг наверное относятся к обслуге дебуг модуля проца, который не рекомендуют выкидывать даже в финальных проектах...

Секция текст - обычно в нее кладут исходники программы, чтобы во время отладки лазить по тексту и видеть откуда что. Я не помню точно, но вроде у эклипса тоже есть галочка включать текст программы или нет в бинарь.

-----
нашел 2 флажка в настройках проекта
omit all symbol information
debug level: min, normal, max, none
вот их еще можно покрутить
pepelats
Цитата(Golikov A. @ Apr 2 2014, 10:33) *
погодите погодите!
у вас размер программки 12 КБ, а откуда вы берете цифру 48? Если в измеряете выходной файл что в ПЛИС заливается, то 1 он в АСКИ формате а не бинарь, то есть все данные побиты на пакеты, снабжены контрольной суммой, заголовком и адресами. Каждый байт представлен двумя и кроме прошивки содержит еще сам проц, конфигурацию железа.

вот вывод в консоль списка файлов. Файл dummy_hi_unit.elf это сам бинарник как я понимаю. По крайней мере в Linux так. Размер как видно показывает 48869.
Код
/Release> ls -l
итого 224
-rwxr-xr-x 1 enovikov users 48869 апр  2 08:55 dummy_hi_unit.elf
-rw-r--r-- 1 enovikov users   247 апр  2 08:55 dummy_hi_unit.elf.elfcheck
-rw-r--r-- 1 enovikov users   107 апр  2 08:55 dummy_hi_unit.elf.size


Цитата(Golikov A. @ Apr 2 2014, 10:33) *
нашел 2 флажка в настройках проекта

Че то не нашел, это в какой вкладке?
Golikov A.
на проект правой кнопкой
C/C++ Build settings
MicroBlaze gcc compiler -> debuger ->...
Microblaze gss linker -> general ->...

ну так elf то это не только программа... там же куча служебки, да еще сам проц вроде там...
pepelats
Цитата(Golikov A. @ Apr 2 2014, 13:16) *
ну так elf то это не только программа... там же куча служебки, да еще сам проц вроде там...

Но в любом случае все это пришлось бы размещать в BRAM если бы понадобилось отказаться от DDR ? У меня как раз загвоздка в этом.

Цитата(Golikov A. @ Apr 2 2014, 13:16) *
Microblaze gss linker -> general ->...

Вот тут кстати помогло. Поставил галочку omit all symbol information и размер файла уменьшился до ~9 кбайт. Надо будет проверить заведется с ним или нет.
Спасибо! a14.gif
Golikov A.
Цитата
Но в любом случае все это пришлось бы размещать в BRAM если бы понадобилось отказаться от DDR ? У меня как раз загвоздка в этом.

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

Проект в БРАМ приятен еще тем что не надо писать загрузчик, который нужен при запуске из DDR.

Цитата
Поставил галочку omit all symbol information и размер файла уменьшился до ~9 кбайт

только отлаживать такой проект невозможно, все имена переменных, функций и прочее выкинуты....
pepelats
Цитата(Golikov A. @ Apr 2 2014, 14:02) *
в брам ложится только (код + данные + текст), куча служебки отрежется при программировании, а сам проц ляжет во внутря плис.

Это точно? Насколько я себе представлял, что проц находится в bitstream, а в ELF файле находится полностью моя софт программа пускай даже с мусором. Но что значит там находится и проц? Помимо FPGAшной реализации есть еще и софтовая часть?

Цитата(Golikov A. @ Apr 2 2014, 14:02) *
Вы если по размеру кода за брамы вылетите, вам про это линкер скажет при сборке, это как раз тот размер что 12 КБ был, когда он больше станет, начнутся проблемы, за ним надо следить, а не на общий размер смотреть.

OK, если это так, то очень хорошо. sm.gif

Цитата(Golikov A. @ Apr 2 2014, 14:02) *
Проект в БРАМ приятен еще тем что не надо писать загрузчик, который нужен при запуске из DDR.

Кстати как раз вопрос. Подскажите, где можно почитать как надо зашить ELF файл во FLASH (желательно Platform Flash), чтобы он по старту питания загрузился в BRAM и начал исполнение? Я находил и делал только с BPI flash, которой нужен SREC загрузчик и много танцев с бубном.
Golikov A.
Цитата
Это точно? Насколько я себе представлял, что проц находится в bitstream, а в ELF

нет это не точно, но я смотрю на размер ELF файла и размер кода у себя, и понимаю что там далеко не только программа... может самого проца там и нет, но куча говна точно имеется, может исходники в текстовом виде для дебага... не знаю, не копал.
Но что смотреть надо на ту цифру что у вас была 12 КБайт, это точно, как она переваливает за размер БРАМ, так вам сразу радостно бежит линкер это рассказать.



Цитата
Кстати как раз вопрос. Подскажите, где можно почитать как надо зашить ELF файл во FLASH (желательно Platform Flash), чтобы он по старту питания загрузился в BRAM и начал исполнение? Я находил и делал только с BPI flash, которой нужен SREC загрузчик и много танцев с бубном.


Эта плис умеет конфигурить свои внутренние BRAM во время конфигурации, так что если ваша программа влезла в БРАМ, то вы просто прошиваете плис как обычно, а во время загрузки она скачает прошивку, законфигурица как проц, и модули памяти подключенные к процу будут уже иметь прошивку. Чтобы так залить программу ничего делать не надо, прямо в SDK жмете xilinx tool -> config FPGA -> выбирает не bootloop а ваш проект, и прошиваете.

Там как то не сложно можно разобраться как сделать это навсегда, а не временно. У меня нет под рукой проекта что влезает в БРАМ чтобы это сделать и написать точнее. А вот если проект в БРАН не влазит, то вот тогда бубен.... Если коротко то надо написать загрузчик, который будет из конфигурационной флеши ПЛИС из места после прошивки брать данные, и пихать их в себя и ДДР. По этому поводу есть апликейшен ноты надо читать на ксалинксе. Вроде как даже есть какой-то стандартный пример. Мой проект с микроблайзом закрылся до этой стадии, мы поставили внешний проц по ряду причин, так что разобраться во всех нюансах я не успел. Так что дальше самиsm.gif
aabmail
Цитата(pepelats @ Apr 2 2014, 13:33) *
Кстати как раз вопрос. Подскажите, где можно почитать как надо зашить ELF файл во FLASH (желательно Platform Flash), чтобы он по старту питания загрузился в BRAM и начал исполнение? Я находил и делал только с BPI flash, которой нужен SREC загрузчик и много танцев с бубном.


ELF во flash можно зашить через iMPACT. А SREC-bootloader можно автосгенерировать в SDK. Он работает (я проверял), только не забудьте оттуда убрать вывод в консоль, иначе программа будет загружаться несколько часов.
pepelats
Цитата(Golikov A. @ Apr 2 2014, 19:13) *
она скачает прошивку, законфигурица как проц, и модули памяти подключенные к процу будут уже иметь прошивку. Чтобы так залить программу ничего делать не надо, прямо в SDK жмете xilinx tool -> config FPGA -> выбирает не bootloop а ваш проект, и прошиваете.

Да, что то подобное делается когда прошивается SREC bootloader.

Цитата(Golikov A. @ Apr 2 2014, 19:13) *
этой стадии, мы поставили внешний проц по ряду причин, так что разобраться во всех нюансах я не успел. Так что дальше самиsm.gif

Спасибо, основное я вроде понял. beer.gif


Цитата(aabmail @ Apr 2 2014, 20:26) *
ELF во flash можно зашить через iMPACT. А SREC-bootloader можно автосгенерировать в SDK. Он работает (я проверял), только не забудьте оттуда убрать вывод в консоль, иначе программа будет загружаться несколько часов.

Да, я делал такое и наступал на грабли со скоростью загрузки. Особенно когда скрость стоит 9600 smile3046.gif
Krys
Цитата(Golikov A. @ Apr 2 2014, 09:33) *
omit all symbol information
Попереключал галочку. Размер секции .text не изменился ни на байт.
Вот тут говорится, что там только исполняемый код:
Embedded System Tools Reference Manual, UG111 (v14.6) June 19, 2013, стр. 108
Непонятно: и чего эту секцию текстом назвали? Для запутывания вероятного противника? )))
Golikov A.
вообще секция текс - это и есть исполняемый код.

А симбол информация - это если не ошибаюсь имена функций и переменных, которые подставляются когда вы в отладке идете по шагам на месте вызова. Это наверное в секцию дебуг попадает.
Krys
Цитата(Golikov A. @ Dec 18 2014, 18:58) *
вообще секция текс - это и есть исполняемый код.
Мне просто помнится, что Вы писали выше, что в тексте хранятся тексты для дебага.

Цитата(Golikov A. @ Dec 18 2014, 18:58) *
А симбол информация - это если не ошибаюсь имена функций и переменных, которые подставляются когда вы в отладке идете по шагам на месте вызова. Это наверное в секцию дебуг попадает.
Ну вот я попробовал эту галочку, у меня вообще размер файла никак не поменялся, не только одна секция текст.

Цитата(Golikov A. @ Dec 18 2014, 18:58) *
А симбол информация - это если не ошибаюсь имена функций и переменных, которые подставляются когда вы в отладке идете по шагам на месте вызова. Это наверное в секцию дебуг попадает.
Вообще конечно странно: зачем программе-отладчику, выполняемой на мощном компе с кучей памяти, хранить какую-то вспомогательную для себя информацию прямо в прошивке? В прошивке и так бывает каждый байт экономят, а отладчик мог бы взять эту инфу у себя в куче памяти, ведь совершенно все исходники у него есть... Нелогично просто...
Golikov A.
Взяли проц с программой, подключились дебагером и давай отлаживать. А в нем все переменные вместо RD9102003 имеют человеческие имена, чем плохо? Если у разработчика есть место на отладочную информацию почему нет?

Храниться оно может вместе с бинарем (то есть в тексте), в отдельном файле, или в отдельной секции в зависимости от реализации среды. У вас где-то в сообщения проскакивало наличие некой секции debug, вот я и предположил что там ваша симбол информация. У себя если честно я что-то не помню такой секции, и единственное где она может лежать это .text или отдельный файл. И если я не ошибаюсь у меня размер текст менялся в зависимости от того сохраняю я или нет символьную информацию.

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

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.