Jump to content
    

Dvorkin

Участник
  • Posts

    40
  • Joined

  • Last visited

Reputation

0 Обычный

About Dvorkin

  • Rank
    Участник
    Участник

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1,407 profile views
  1. Данные в ПЛИС не надо накапливать, передавайте их по мере поступления. Принятые 64-битные слова пишутся в FIFO, если в FIFO есть данные, то TVALID=1, можно передавать по DMA.
  2. Есть вектор, все работает. Может, файл у вас не .cpp а .c?
  3. Для petalinux 2020.1 применял такой патч ядра (project-spec/meta-user/recipes-kernel/linux/linux-xlnx/xilinx_uartps_patch.patch): Ну, и надо включить патч в project-spec/meta-user/recipes-kernel/linux/linux-xlnx_%.bbappend: SRC_URI_append += " file://xilinx_uartps_patch.patch"
  4. Проще всего установить Xilinx SDK или Vitis. В нем компилить и отлаживать приложение под Linux. Готовый образ Linux есть на сайте Xilinx. Можно установить petalinux и собрать свой образ. Плюс такого подхода - можно включать нужные опции ОС и библиотеки. Можно и компилить свое приложение компилятором из petalinux. Для этого создать SDK (petalinux-build --sdk), затем установить переменные окружения: source images/linux/sdk/environment-setup-aarch64-xilinx-linux и, как обычно, вызывать $(CROSS_COMPILE)gcc. Это метод для встраивания своего приложения в RootFS (готового, отлаженного). А не для разработки и отладки.
  5. Xilinx перешел с компилятора на eabi-hf. Примерно с 2017.4. Бинарники, собранные с eabi-hf не будут выполняться в файловой системе, собранной с eabi, и наоборот. Вот прямо так и скажет - нет такого файла, хотя +x установлено.
  6. Это уже включено в 2020.1, но проблема не решилась...
  7. Очень похоже на зависание при ожидании готовности генератора случайных чисел. Лечится включением IMAGE_INSTALL_append = " haveged" в petalinuxbsp.conf См. Xilinx AR# 72377
  8. Что за патч, можно глянуть?
  9. Было примерно то же самое - сборка в petalinux 2019.1 работала с NAND, а 2020.1 - нет, так же ругается на bbt. Боремся по сей день.
  10. Ну, если все так просто - то конечно. У меня малость сложнее. Хотел встроить свой код в U-boot, да не получается...
  11. Все это хорошо было в Zynq. А вот в ZynqMP Ultrascale размер FSBL ограничен, часть OCM отдана под FSBL, часть под ATF. Сильно не разгуляешься...
  12. Требуется char*, а передается unsigned char* Наверное, все же: n[2]=0;
  13. Кроме ошибки обновления прошивки могут быть и глюки в рабочей программе (app_a53_X.elf). По самым разным причинам, человеческий фактор никто не отменял, увы. Или повреждения рабочей прошивки в процессе работы. Могу предложить такой алгоритм: 1) Рабочая программа после успешного запуска сбрасывает счетчик загрузок. 2) Стартует сначала резервная прошивка, в FSBL делается проверка счетчика загрузок, если он меньше N, то: 2.1) счетчик инкрементируется, в MultiBootReg записывается адрес рабочей прошивки (ну, или просто инкремент), делается soft reset, грузится рабочая прошивка. 2.2) иначе ничего не делается, продолжается загрузка резервной прошивки. Счетчик может храниться в специально выделенном разделе FLASH.
  14. Можно прочитать /dev/mtd1 (который bootenv) и посмотреть, в каком формате хранятся переменные u-boot. Не маловат размер раздела 11 МБ для RootFS? И вообще, QSPI всего 32 МБ, проще грузиться с SD и хранить переменные u-boot в uEnv.txt
×
×
  • Create New...