Dimonira

Платный контроллер?! Не может быть! 😉 Про интерфейс SPI - может попробовать тактовую частоту уменьшить?

Да, думаю ещё разобраться с микро SD-картой и выходом HDMI. Наскоком не получилось, надо разбираться.

Спасибо за ответ. 1. Доступ в интернет есть, я это сразу указал. 2. Запущен ли ntpd: Так что попробовал рекомендуемое: Так что ntpd запущен. 3. Состояние: В логе от ntpd как раз всегда идёт жалоба на таймаут, типа никто ему не отвечает. Подозреваю, что ntpd запущен не с теми параметрами, которые нужны для работы через интернет. Но где рыть - не знаю.

Доброго дня! В своей теме тут описывал успешно завершившийся запуск Petalinux 2013.1 на Microblaze. В результате я получил систему, в которой есть гигабитная сеть, есть доступ в интернет (удалённые сервера пингуются). Однако дата/время через интернет по NTP не синхронизируются. Делал поиск в интернет, нашёл следующее предложение: добавить в файл: строку: и построить Petalinux, в котором окажутся указанные службы. Сделал, перестроил, все из ntp ntpdate ntpq sntp появились, но время не синхронизируется всё равно. Содержимое файла /etc/ntp.conf такое: Лог загрузки показывает, что ntpd что-то пытается, но коннекта сделать не может и прерывается по таймауту. Я в линуксах не силён, что ему не хватает? Надо как-то настроить?

Всё, в главном вроде разобрался, линукс стартует стабильно, плата работает от одного порта хаба. Правда, пока оставил ext_spi_clk = 50МГц, т.е. флешка тактируется 25 МГц, потому ядро из флешки грузится примерно 20 с - долго. Сначала я изменил настройки microblaze - руками переключил кэш инструкций и данных на всю память DDR, ибо почему-то вивада автоматически устанавливала кэш на периферию. После этого ядро начало стабильно грузится, но начинало паниковать при попытке подключения к ethernet: После этого беглый поиск по сети навёл на мысль, что надо поменять интерфейс axi_ethernet с процессором с fifo на dma. Проделов это, пересобрав проект и линукс, я получил те же результаты - панику ядра. Лог загрузки практически был такой же, так что не привожу. Обратил внимание на эту строчку лога: Стало понятно, что ядро не знает про PHY. В дереве устройств про него не было ничего. Тогда добавил в этот файл (в проекте petalinux): следующие строки, сразу за теми, что уже были в начале (это есть в видео, о котором было в первом посте, но часть строк уже была в генерируемом дереве, так вставлял только отсутствующие): phy@1 соответствует адресу phy на шине mdio, в моём случае = 1. Далее пересобрал проект petalinux и прошил флешку. В итоге всё грузится, паники ядра нет, сеть видна, 1 гигабит, пинг есть. Eset сообщил об обнаружении нового устройства в сети. Лог загрузки u-boot (сразу после отсчёта 4 секунд) и ядра:

Радость была недолгой. На следующий день я слегка поменял настройки системы, после чего загрузка снова прекратилась. Самое интересное, что прошитый вчерашний проект, тоже не загружался, хотя загружался накануне. Потом я снова почитал документацию - PG153 и оказалось, что я делал тактовую частоту ext_spi_clk 100МГц, что судя по таблице недопустимо: Причём, указанные клоки для режима SPIx1, а для других неведомы. Я сделал 66.6, но это тоже не помогло. Сейчас 50 - безрезультатно. Добавил констрейны для QSPI (из PG153) - лучше не стало. Снова взял осциллограф. Оказалось, что когда крутишь плату в руках и подключаешь землю щупа к земле платы, то она часто загружается как положено. Если ядро уже загрузилось, то дальше глюков нет. Выходит глюки именно при обмене по QSPI. Когда загрузки ядра нет, осциллограф говорит, что импульсов на выходе CCLK нет вообще (есть только в момент загрузки бит-файла в fpga). Если подаю питание и импульсы CCLK какое-то продолжительное время есть, значит загрузка ядра пошла (хотя, может и не до конца). Так что дело было не в питании, все dc/dc на плате выдают нужные напряжения. Основной такт 50 МГц тоже нормальный. Может микросхемы дохлые, флешку брал на Aliexpress, как и саму плату...

Вы, видимо невнимательно читали. Загрузчик fs-boot грузится вместе с плис (а не u-boot) и работает, из флешки загружает код u-boot в память ddr3. Это всё делает microblaze из флешки через контроллер qspi. Значит железо заработало, а дальше не работает u-boot. Причину я только что выяснил. Всё оказалось банально, как только я достал осциллограф и обнаружил, что тактовые импульсы на флешку нестабильны, то они есть, то они пропадают. После того, как я увидел, что была попытка таки начала работы u-boot и загрузка ядра, я задумался, что что-то не так с железкой. Недолго чесал репу и предположил - дело в питании, плате не хватает тока! Дело в том, что плата запитывается от двух USB-C разъёмов - jtag и uart, питание с которых объединено дерез диоды и далее идёт на dc/dc. Плюс, точнее по факту минус: у платы нет кнопки сброса плис на PROG, только на user i/o. В результате для полного сброса надо передёргивать питание. Я плату запитывал двумя кабелями с одного usb3.0 хаба TP-LINK, один из выходов которого 1.5А, другой стандартный. Плата кушает под 0.5А, но, видимо, хаб не даёт такого тока в момент старта (при старте может и больше бросок), и плата встаёт раком. Тогда я подал питание на плату с отдельного блока питания на разъём jtag, причём увеличил до 5.5В (чтобы перекрыть питание с второго usb), а потом подключил к хабу второй конец с uart. И всё пошло! Зря я тужился с настройками и компиляциями u-boot, только время терял. Ладно хоть освоил "тему". Лог загрузки, правда не с самого начала (было 4 секунды, и плюс я пока втыкал и запускал терминал), такой: Из-за того, что в этом проекте нет сетевого контроллера (eth0), на некоторых сетевых моментах ядро тупило, но в итоге дошло до запроса логина. Теперь надо вернуться к предыдущему проекту с ethernet и попробовать его.

Ничего с полным проектом так и не добился. Создал проект попроще, только процессор, ddr3, uart, gpio, timer, qspi: Далее сделал всё аналогично предыдущему, настроил только адреса и размеры, а настройки rootfs и u-boot не менял. После этого u-boot таки загрузился! Но радость была короткой: u-boot почему-то не захотел увидеть флешку и что-либо грузить с неё. Лог при старте такой: Далее зависает. Иногда возникает исключение: Прервав выполнение u-boot, я попробовал команду из boot.scr, которая инициализирует флешку: Именно на ней u-boot и зависает. В чём может быть проблема? Может частота клоков большая, 50 МГц? Но флешка может вдвое больше. Странно, fs-boot работал с флешкой без проблем, хотя в конфигурации стоит 33 МГц. Похоже без осциллографа не обойтись.

Опять вернулся к FS-BOOT. Подхожу отладчиком к команде перехода на начало u-boot на адрес 0x80100000. Вызвал окно дизассемблера. Но после нажатия на шаг вперёд ничего не происходит! Процессор стоит на месте! Если нажать на паузу, то возникает окно, где об этом сообщается - процессор стоит на адресе 0xb5c: Причём, если посмотреть содержимое регистров, то адрес точки перехода 0x80100000 в регистре r7, но этот регистр в команде перехода не участвует! А далее команды зацикливания, там процессор и стоит. Получается, что до u-boot дело не доходит. В чём может быть проблема? Кэш? Но вроде он отключается в начале FS-BOOT: XCACHE_DISABLE_CACHE();

Конечно u-boot не сконфигурирован, как оказалось... Посмотреть какой реальный endian у Microblaze можно в файле design_1_wrapper.mmi, в котором приводится описание памяти (как раз для внедрения FS-BOOT в бит-файл): А вот с u-boot сложнее. Как выяснилось, он почему-то оказался настроен под virtex5 и big endian! Для его конфигурирования делается команда: После её запуска придётся подождать, пока не появится окно конфигуратора. Кратко пока поменял вот что: MicroBlaze architecture-> (0x1F00000) Boot script offset [не менял, просто для справки, что оно тут - смещение для размещения boot.scr] MicroBlaze architecture-> (artix7) Targeted FPGA family [было: virtex5!!!] Endianness selection (Little endian) [было: Big endian!!!] API->[ ] Enable U-Boot API [?наверное можно при надобности выбрать, оставил] Boot options->Boot media->[*] Support for booting from QSPI flash [не обязательно, но по-моему укоротит скрипт boot.scr до запуска сразу с заданного места - QSPI flash] Boot options->[ ] Enable preboot [снял галку, вроде мне не нужно] Device Drivers->Ethernet PHY (physical media interface) support [отключил ненужные PHY] (где-то включил RGMII, посмотреть, может ещё что-то ненужное отключить) Компиляция... Пока не пошло 😞

Продолжил разбираться. Создал проект на основе шаблона mba_fs_boot для отладки FS-BOOT: Конечно, без обычного обряда танца с бубном не обошлось - проект не собирался из-за ошибок, вызванных отсутствием нескольких определений констант. Одно из определений - CONFIG_PRIMARY_FLASH_SPI. Судя по всему, это определяется в проекте Petalinux, а Vitis про это не знает. Другие константы - адреса и размеры, которые в заголовке xparameters.h, описывающем аппаратуру платы, есть, но имена имеют другие. Так что для успеха компиляции добавил в fs-boot.h (после #include "xparameters.h") следующие строки: #define CONFIG_PRIMARY_FLASH_SPI #define CONFIG_FS_BOOT_OFFSET 0x400000 #define CONFIG_XILINX_ERAM_SIZE (XPAR_MIG_7SERIES_0_HIGHADDR-XPAR_MIG_7SERIES_0_BASEADDR) #define CONFIG_XILINX_ERAM_START XPAR_MIG_7SERIES_0_BASEADDR #include "spi-flash.h" Включить spi-flash.h пришлось из-за ругани компилятора на отсутствие объявления функции spi_flash_read. CONFIG_FS_BOOT_OFFSET = 0x400000 - это адрес старта размещения u-boot в флешке (точнее на заголовок перед ним). А в файл xspi.h в аналогичное место вставил это: #define CONFIG_PRIMARY_FLASH_SPI_BASEADDR XPAR_AXI_QUAD_SPI_0_BASEADDR #define CONFIG_FLASH_SPI_MODE XPAR_AXI_QUAD_SPI_0_SPI_MODE #define CONFIG_FLASH_SPI_FIFO_DEPTH XPAR_AXI_QUAD_SPI_0_FIFO_DEPTH Для избегания пары предупреждений пришлось убрать volatile в вызовах spi_flash_read. Но это не критично. Далее запустил отладку и пошёл. Выяснилось, что: 1. FS-BOOT выполняется корректно. 2. Смещение для поиска u-boot в флешке записано корректно, а вот Xilinx дезинформировал, что размер u-boot берётся из заголовка по смещению 0x4. На самом деле целевой адрес загрузки и размер u-boot читаются как два соседних слова, в итоге всё корректно: 0x80100000 - целевой адрес загрузки 0x000808F8 - размер u-boot (526584 байта), точно, как на самом деле размер файла u-boot.bin. 3. Слово 0x9400c001, которое было непонятно, на самом деле первое слово кода u-boot. Оно как раз находится по смещению 0x10C и называется в руководстве как "Where the BIN file start". Следующие картинки всё показывают, в том числе отличие u-boot.bin от u-boot-s.bin (последний тот же u-boot.bin, но с заголовком в начале). В итоге FS-BOOT корректно реально загружает u-boot в DDR3 (видно на картинке по дампу памяти с началом в 0x80100000) и передаёт управление на его начало. В терминале я вижу: А вот дальше - тишина. Не работает u-boot! Почему - непонятно. Во весь рост встаёт вопрос о endian. Я с Microblaze детально не знаком и по двоичному коду не могу понять какой endian. Может знает кто? Или есть другие идеи? Надо разбираться с u-boot... Или с endian у Microblaze, попробую покрутить его настройки.

Всем привет! После минимального освоения сборки и загрузки линукса в Zynq-7, надо освоить аналогичные действия на софтовом Microblaze. Имеется плата Microphase A7-Lite с установленными fpga XC7A100T-2FGG484, DDR3 MT41K256M16TW-107:P (D9SHD), QSPI flash, RGMII RTL8211E, HDMI, EEPROM, 2xLED, 3xBUTTON . Сразу скажу, что по мере освоения стало понятно, что установленного QSPI flash 16МБ для этих целей недостаточно. Так что заменил IS25LP128FBLE (16МБ) на MX25L25645GM2I-10G (32МБ). Подключение: Чтобы не парить мозг каждый раз назначением ножек и т.п., когда делается новый проект для этой платы, сделал для платы "пакет поддержки", чтобы процесс был аналогичен прочим готовым платам для разработчиков. Дело не сильно хитрое, но пришлось пройти обряд танцев с бубном, ибо, если что-то Vivado не понравится в файлах описания платы, то он тупо ничего не скажет, просто платы в общем списке плат не окажется. Далее, посмотрев видео о том, как быстро "поднять" Petalinux + Microblaze на другой похожей по сути плате Arty A7-100 и почитав документацию, собрал свой проект в Vivado: Настройки ограничений касались только QSPI: Чтобы флешка стала загрузочной, выставил соответствующую опцию (она disable, т.к. параметры настройки корки сделаны в "пакете поддержки"): Далее стандартные шаги по компиляции, экспорту оборудования в файл. Затем переход на виртуальную машину vmware с установленной Ubuntu, Vivado, Petalinux и прочим зоопарком. Запускаю терминал в папке, в которой будет создан проект с именем "qspi". 1. Начальные действия по созданию проекта Petalinux: 2. Копирую в папку проекта файл описания оборудования, экспортированный из Vivado. 3. Запускаю конфигурирование проекта в соответствии с оборудованием: Когда откроется окно конфигуратора, делаю следующие настройки. Снимаю галку TFTPD: Задаю настройки областей в памяти QSPI Flash: Область spi0-fpga для бит-файла fpga, модифицированного внедрённым кодом загрузчика первого этапа FS-Boot. С запасом - 4 МБ. Область spi0-boot - для загрузчика u-boot. Его размер чуть более 526 кБ, так что взял с запасом 1 МБ. Область spi0-bootenv - резерв под bootenv, тоже взял с запасом, округлив для простоты до 1 МБ (хотя столько не надо). Область spi0-kernel - под образ ядра линукс, точнее, FIT-файл image.ub, составленный из следующего (содержимое готового файла, взято командой dumpimage -l image.ub, но это уже после компиляции): Почему 0x1900000 (25МБ) - чуть ниже. Задаю настройки u-boot, находящиеся здесь: Меняю только те, что для FIT-образа (мой случай): Офсет взят исходя из того, что перед FIT образом в flash лежат: fpga=4МБ + u-boot=1МБ + bootenv=1МБ = 6МБ => 0x600000. Размер под FIT образ взят до конца размера флешки 32МБ с учётом того, что в последний 1МБ пишется скрипт загрузки boot.scr: 32МБ (0x2000000) - 6МБ - 1МБ = 25МБ (0x1900000). Почему-то эти настройки человек из видео не делал, но у него всё запускается и грузится (правда, у него Vivado 2018). В документации (UG1144, стр.69) прямо написано: 4. В конце надо сохранить конфигурацию. После выхода из конфигуратора будет сгенерирована конфигурация проекта. 5. Конфигурирование файловой системы rootfs (можно выбрать программы для установки, но это увеличивает размер образа!): Я выбрал только эти две (вторая в надежде на то, что система будет время синхронизировать по NTP, но не знаю как в деле): В видео человек ещё выбирал Python и с ним всё умещалось в 16МБ на его плате Arty-A7. В моём случае можно было выбрать только Python3, но это увеличивает размер image.ub до 25МБ, что под завязку или не влезет в 32МБ (6МБ ведь занято уже). Далее сохраняем настройки и выходим. 6. Запускаю построение petalinux: 7. После успешной сборки выходные файлы образов будут в папке images/linux: На всякий случай, вот содержимое файла boot.prm: 8. Подготовка окружения Vivado (у вас путь установки Vivado может отличаться): 9. Генерация mcs файла для прошивки (у вас название бит-файла может отличаться): Лог: 10. Далее стандартная процедура прошивки итогового файла boot.mcs в QSPI flash средствами Vivado. 11. Теперь о грустном. Система НЕ запускается! Судя по логу, который я ловлю терминалом: FPGA успешно загружается и загрузчик первого этапа FS-BOOT запускается и начинает работать (по крайней мере выводит в лог сообщения). И раз он работает, значит работает и проект, во всяком случае Microblaze+BRAM+UART+клоки. Но FS-BOOT работает из локальной памяти FPGA и должен загрузить уже во внешнюю DDR3 следующий загрузчик - U-BOOT, но судя по всему этого то и не происходит. В чём могут быть грабли? Читая документацию, я так до конца и не понял, как работает вывод CCLK? В начале понятно, выдаёт клоки на загрузку бит-файла в FPGA, но что потом в USER-MODE, будут клоки идти или нет? Бит настройки "Enable STARTUP primitive" я установил, но достаточно ли этого? В документации нет конкретики (или не нашёл). Осциллографом пока поленился тыкать, надо делать "преобразования" на столе. Другой момент. Я посмотрел содержимое итогового файла прошивки boot.mcs. По смещению 0x400000 (после бит-файла), где должен находится u-boot, я вижу заголовок: Где (см. UG1144 стр.200): 0xb8b40008 - маркер 0x80000000 - размер BIN-образа 0x80100000 - стартовый адрес загрузки образа, по которому FS-BOOT загружает U-BOOT 0x9400c001 - где начинается BIN-образ Непонятно второе и последнее значения. Ну, размер ладно, больше - не меньше. Но адрес 0x9400c001 откуда взят? И что это за адрес, внутри флешки или в адресном пространстве Microblaze? В проекте память Microblaze распределена так: Ничего похожего на 0x9400c001 не наблюдаю. Во всяком случае, U-BOOT лежит во флешке и смещение по идее должно быть взято оттуда. И ещё. Есть подозрения на endian. Я так и не понял, на видео у человека после загрузки системы в логах видно, что Microblaze работает в little-endian. Но в документации (UG984) написано: Но у меня как раз и стоит в настройках Microblaze Linux MMU + Virtual (как в видео). Плюс я где-то видел при компиляции big-endian, но где не могу вспомнить. Сам я ничего не менял, даже непонятно где это выставляется, видимо косвенно. Где искать проблему? PS. Работоспособность DDR3 проверил в другом проекте bare-metal на Microblaze с использованием моего "пакета поддержки" и стандартного шаблона mem_test - работает.

1. Взять другой кабель, который быстрее. 2. Процессор внешний, ему то откуда грузиться? Он про битстрим ничего не знает. Для него нет своей памяти программ. Есть только EEPROM для ПЛИС, которая подключена к ПЛИС, а не к процессору. А сложности для простоты использования (в одну EEPROM шьётся всё) и уменьшения количества корпусов микросхем на плате.

Скорось можно увеличить более быстрым кабелем. У меня SMT2-HS работает довольно шустро. На uart обычно перенаправляют stdout, через который работает printf и т.п. Настраиваться должно в пакете поддержки. (ISE последний раз использовал лет 15 назад). Прошивку процессора не надо засовывать внутрь битстрима, хотя и можно - я делал в ПЛИС ядро ROM 256х32, в которое засовывал начальный загрузчик для процессора, правда внешнего ADSP-TS201, который начинает выполняться процессором (надо чтобы ПЛИС загрузилась раньше старта процессора). Прошивка складывается в загрузочную память (флешку и т.п.) и загружается в память процессора после загрузки битстрима в ПЛИС. В случае отладки, отладчик сам загружает битстрим, а потом программу в процессор и останавливает программу в начальной точке.

Смотрел. Там мало что объясняется. Шаг влево, шаг вправо - неизвестность. И до успешного результата ничего не доведено. Пока что я понял, что в доках Xilinx всё заточено под Petalinux, так что image.ub - это там. Если компилировать u-boot самому, то всё будет по-другому. Разбираю... ------------------------------- В итоге победил, система грузится из image.ub. Изучая окружение u-boot, которое я получил с помощью команды printenv, я понял, что мне эти скрипты не осилить. Точнее, не сами скрипты, а как их поменять в настройках конфигурации u-boot. В итоге я решил попробовать простой путь - изменить переменную окружения bootcmd, которая изначально была определена так Эта distro_bootcmd выполняет различные варианты загрузки с разных устройств и по сети. Мне это всё вроде не нужно (для платы), поэтому заменил команду на следующие: Команду вводил в этом меню конфигурирования u-boot: Больше ничего не менял, запустил сборку u-boot. После этого пересобрал boot.ini с новым u-boot.elf и записал на SD-карту файлы boot.ini и image.ub. Система загрузилась без проблем. Лог загрузки следующий: Окружение для нового u-boot стало таким: Сделал сравнение окружения для прежнего u-boot и нового: Чтобы получить окружение u-boot, я временно переименовал image.ub, чтобы он не грузился. В итоге u-boot после замены bootcmd заканчивает попытку загрузки очень быстро: Никаких попыток загрузки с других источников нет. Так что получилось топорно, но я пока не силён в линуксах.