Jump to content

    

Dvorkin

Участник
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Dvorkin

  • Rank
    Участник

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1195 profile views
  1. Для 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"
  2. Проще всего установить 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 (готового, отлаженного). А не для разработки и отладки.
  3. Xilinx перешел с компилятора на eabi-hf. Примерно с 2017.4. Бинарники, собранные с eabi-hf не будут выполняться в файловой системе, собранной с eabi, и наоборот. Вот прямо так и скажет - нет такого файла, хотя +x установлено.
  4. Это уже включено в 2020.1, но проблема не решилась...
  5. Очень похоже на зависание при ожидании готовности генератора случайных чисел. Лечится включением IMAGE_INSTALL_append = " haveged" в petalinuxbsp.conf См. Xilinx AR# 72377
  6. Что за патч, можно глянуть?
  7. Было примерно то же самое - сборка в petalinux 2019.1 работала с NAND, а 2020.1 - нет, так же ругается на bbt. Боремся по сей день.
  8. Ну, если все так просто - то конечно. У меня малость сложнее. Хотел встроить свой код в U-boot, да не получается...
  9. Все это хорошо было в Zynq. А вот в ZynqMP Ultrascale размер FSBL ограничен, часть OCM отдана под FSBL, часть под ATF. Сильно не разгуляешься...
  10. Требуется char*, а передается unsigned char* Наверное, все же: n[2]=0;
  11. Кроме ошибки обновления прошивки могут быть и глюки в рабочей программе (app_a53_X.elf). По самым разным причинам, человеческий фактор никто не отменял, увы. Или повреждения рабочей прошивки в процессе работы. Могу предложить такой алгоритм: 1) Рабочая программа после успешного запуска сбрасывает счетчик загрузок. 2) Стартует сначала резервная прошивка, в FSBL делается проверка счетчика загрузок, если он меньше N, то: 2.1) счетчик инкрементируется, в MultiBootReg записывается адрес рабочей прошивки (ну, или просто инкремент), делается soft reset, грузится рабочая прошивка. 2.2) иначе ничего не делается, продолжается загрузка резервной прошивки. Счетчик может храниться в специально выделенном разделе FLASH.
  12. Можно прочитать /dev/mtd1 (который bootenv) и посмотреть, в каком формате хранятся переменные u-boot. Не маловат размер раздела 11 МБ для RootFS? И вообще, QSPI всего 32 МБ, проще грузиться с SD и хранить переменные u-boot в uEnv.txt
  13. Отформатировать раздел /dev/mtd3, например, в ext4, и распаковать в него rootfs.tar.gz В bootargs указываете root=/dev/mtd3 rw rootwait rootfstype=ext4
  14. Есть полезная утилита для проверки INF: "C:\Program Files (x86)\Windows Kits\8.1\Tools\x86\ChkInf\chkinf.bat”