doom13 0 22 октября, 2019 Опубликовано 22 октября, 2019 · Жалоба Приветствую. Вопрос по MultiBoot для Kintex UltraScale+. Пока сгенерировал два bit-файла с настройками для golden image: set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property BITSTREAM.GENERAL.CRC ENABLE [current_design] set_property BITSTREAM.CONFIG.CONFIGRATE 31.9 [current_design] set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR YES [current_design] set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design] set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design] set_property BITSTREAM.CONFIG.TIMER_CFG 0x00050000 [current_design] set_property BITSTREAM.CONFIG.NEXT_CONFIG_REBOOT Enable [current_design] set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 0x01000000 [current_design] для multiboot image: set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property BITSTREAM.GENERAL.CRC ENABLE [current_design] set_property BITSTREAM.CONFIG.CONFIGRATE 31.9 [current_design] set_property BITSTREAM.CONFIG.SPI_32BIT_ADDR YES [current_design] set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design] set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design] C нулевого адреса лежит golden.bit, multiboot.bit ложится с адреса 0х01000000 и успешно стартует. Как понимаю, в шапке golden.bit содержится адрес 0х01000000 старта multiboot.bit и на него и переходит. Вопрос в том, если вместо multiboot.bit залить multiboot.bin (уже без шапки) так же всё работает. Но если заливку multiboot.bin прервать, то система больше не грузится (вроде должна остаться в golden). Что не так тут делаю? Если потом просто стереть область памяти, куда ложился multiboot.bin система начинает запускаться с golden_image. Ещё читаю про HWICAP, но не совсем понятно, обязателен ли он для реализации MultiBoot. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 24 декабря, 2019 Опубликовано 24 декабря, 2019 · Жалоба Приветствую. Поделитесь опытом по реализации MultiBoot для ZynqMP. Интересует сам принцип механизма. Правильно ли понимаю, что тут нет возможности перебросить загрузчик на нужный адрес, будет искать валидный хедер через каждые 32кБ? Только так? Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 25 декабря, 2019 Опубликовано 25 декабря, 2019 · Жалоба Один вопрос: А зачем это в цинке, если я могу играть битстримами как душе угодно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 26 декабря, 2019 Опубликовано 26 декабря, 2019 · Жалоба On 12/25/2019 at 9:31 AM, gosha-z said: Один вопрос: А зачем это в цинке, если я могу играть битстримами как душе угодно? Загрузка с QSPI. Смотрю, что умеет стартануть более свежую прошиву, которая лежит во flash. Если эту более свежую частично испортить, то можно получить нерабочую систему без возможности её восстановления. Вопрос, как сделать так, чтоб при сбое во время обновления конфигурационной QSPI система могла всегда быть восстановлена? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 26 декабря, 2019 Опубликовано 26 декабря, 2019 · Жалоба Вам нужен битстрим до убута? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 26 декабря, 2019 Опубликовано 26 декабря, 2019 · Жалоба 2 hours ago, gosha-z said: Вам нужен битстрим до убута? Уже нет убута и Linux. Нужно чтобы система позволяла безопасно обновить ПО в QSPI. Пока поддерживает перепрошивку QSPI, но если произошёл сбой в процессе перепрошивки QSPI, то система превращается в кирпич. Нашёл, что есть такая фишка, как MultiBoot (что успешно реализовано для платы с Kintex UltraScale+), но не совсем понимаю, как правильно реализовать его поддержку в случае ZynqMP. Пока протестил, что если положить две прошивки (первая golden image, которая никогда не перезаписывается, и вторая, которая будет обновляться), то будет стартовать более новую версию прошивки, которая и обновлялась. Но, если при перепрошивке рабочего ПО (второго образа) произошёл сбой, могу получить вариант с частично испорченной прошивкой. Система пытается её загрузить, сбрасывается, и так по кругу (или вариант, когда стартует битую прошивку и остаётся в нерабочем состоянии). Golden image никогда не запускается. Вот пытаюсь понять, что тут делаю неправильно и как заставить систему остаться в режиме golden image. Всю систему грузит только FSBL. Читал xilinx-wiki по реализации MultiBoot. Но так и не понял, что они тут советуют. Предлагается перезаписать мултибут регистр и делать сброс системы XFsbl_UpdateMultiBoot while (FsblStage<=XFSBL_STAGE_DEFAULT) { switch (FsblStage) { case XFSBL_STAGE1: { /** * Initialize the system */ FsblStatus = XFsbl_Initialize(&FsblInstance); if (XFSBL_SUCCESS != FsblStatus) { FsblStatus += XFSBL_ERROR_STAGE_1; FsblStage = XFSBL_STAGE_ERR; } else { /** * * Include the code for FSBL time measurements * Initialize the global timer and get the value */ FsblStage = XFSBL_STAGE2; } /** * 24.12.2019 * Edited by Andrei Hres * This code support MultiBoot option. * Application image (IMAGE1) is placed at address 0x04000000. * BootROM will try to find valid boot image at every 32kB offset. * Offset 2048 - start boot at 32768*2048 = 0x04000000 */ XFsbl_UpdateMultiBoot(2048); }break; static void XFsbl_UpdateMultiBoot(u32 MultiBootValue) { u32 RegValue; XFsbl_Out32(CSU_CSU_MULTI_BOOT, MultiBootValue); /** * Due to a bug in 1.0 Silicon, PS hangs after System Reset if RPLL is used. * Hence, just for 1.0 Silicon, bypass the RPLL clock before giving * System Reset. */ if (XGetPSVersion_Info() == (u32)XPS_VERSION_1) { RegValue = XFsbl_In32(CRL_APB_RPLL_CTRL) | CRL_APB_RPLL_CTRL_BYPASS_MASK; XFsbl_Out32(CRL_APB_RPLL_CTRL, RegValue); } /* make sure every thing completes */ dsb(); isb(); if(FsblInstance.ResetReason != XFSBL_APU_ONLY_RESET) { /* Soft reset the system */ XFsbl_Printf(DEBUG_GENERAL,"Performing System Soft Reset\n\r"); RegValue = XFsbl_In32(CRL_APB_RESET_CTRL); XFsbl_Out32(CRL_APB_RESET_CTRL, RegValue|CRL_APB_RESET_CTRL_SOFT_RESET_MASK); /* wait here until reset happens */ while(1) { ; } } else { for(;;){ /*We should not be here*/ } } return; } Попробовал, зациклил систему на старте FSBL и сбросе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 26 декабря, 2019 Опубликовано 26 декабря, 2019 · Жалоба 12 hours ago, doom13 said: Смотрю, что умеет стартануть более свежую прошиву, которая лежит во flash. Что-то не могу повторить полученный ранее результат. Вопрос где хранится timestamp образа и как его туда поместить? Для формирования boot.bin используется bif-файл с содержимым: //arch = zynqmp; split = false; format = BIN the_ROM_image: { [pskfile]/home/user/workspace/xczu9eg/boot/psk0.pem [sskfile]/home/user/workspace/xczu9eg/boot/ssk0.pem [auth_params]spk_id = 0x00000000; ppk_select = 0 [fsbl_config]a53_x64, bh_auth_enable [bootloader, authentication = rsa]/home/user/workspace/xczu9eg/xczu9eg.sdk/fsbl/Debug/fsbl.elf [pmufw_image]/home/user/workspace/xczu9eg/xczu9eg.sdk/pmufw/Debug/pmufw.elf [authentication = rsa, destination_device = pl]/home/user/workspace/xczu9eg/xczu9eg.runs/impl_1/xczu9eg.bit [authentication = rsa, destination_cpu = a53-0, exception_level = el-3]/home/user/workspace/xczu9eg/xczu9eg.sdk/app_a53_0/Debug/app_a53_0.elf [authentication = rsa, destination_cpu = a53-1, exception_level = el-3]/home/user/workspace/xczu9eg/xczu9eg.sdk/app_a53_1/Debug/app_a53_1.elf } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Opex 0 9 января, 2020 Опубликовано 9 января, 2020 · Жалоба У нас в обычном Цинке сделано так: сначала идет рабочая прошивка, затем аварийная. Какой-то встроенный загрузчик ищет волшебную комбинацию байтов, если находит, грузит прошивку. При обновлении, сначала стираются волшебные числа, записывается прошивка, если все записалось хорошо, записываются числа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toshas 0 25 января, 2020 Опубликовано 25 января, 2020 · Жалоба On 1/9/2020 at 8:24 AM, Opex said: У нас в обычном Цинке сделано так: сначала идет рабочая прошивка, затем аварийная. Какой-то встроенный загрузчик ищет волшебную комбинацию байтов, если находит, грузит прошивку. При обновлении, сначала стираются волшебные числа, записывается прошивка, если все записалось хорошо, записываются числа. Это "классический" подход для мультибут по xapp1081, я тоже посоветовал бы сделать по нему https://www.xilinx.com/support/documentation/application_notes/xapp1081-quickboot-remote-update.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dvorkin 1 11 февраля, 2020 Опубликовано 11 февраля, 2020 · Жалоба Кроме ошибки обновления прошивки могут быть и глюки в рабочей программе (app_a53_X.elf). По самым разным причинам, человеческий фактор никто не отменял, увы. Или повреждения рабочей прошивки в процессе работы. Могу предложить такой алгоритм: 1) Рабочая программа после успешного запуска сбрасывает счетчик загрузок. 2) Стартует сначала резервная прошивка, в FSBL делается проверка счетчика загрузок, если он меньше N, то: 2.1) счетчик инкрементируется, в MultiBootReg записывается адрес рабочей прошивки (ну, или просто инкремент), делается soft reset, грузится рабочая прошивка. 2.2) иначе ничего не делается, продолжается загрузка резервной прошивки. Счетчик может храниться в специально выделенном разделе FLASH. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 17 февраля, 2020 Опубликовано 17 февраля, 2020 · Жалоба On 1/9/2020 at 8:24 AM, Opex said: У нас в обычном Цинке сделано так: сначала идет рабочая прошивка, затем аварийная. Какой-то встроенный загрузчик ищет волшебную комбинацию байтов, если находит, грузит прошивку. При обновлении, сначала стираются волшебные числа, записывается прошивка, если все записалось хорошо, записываются числа. Сделал аналогично. On 1/25/2020 at 4:58 PM, toshas said: Это "классический" подход для мультибут по xapp1081, я тоже посоветовал бы сделать по нему Не сразу нашёл эту доку, больше смотрел по ZynqMP, а там предлагают из FSBL делать переброс на рабочую прошивку, работает, но не понял зачем такие сложности, если можно просто поменять их местами. On 2/11/2020 at 3:44 PM, Dvorkin said: Кроме ошибки обновления прошивки могут быть и глюки в рабочей программе (app_a53_X.elf). По самым разным причинам, человеческий фактор никто не отменял, увы. Или повреждения рабочей прошивки в процессе работы. Могу предложить такой алгоритм: 1) Рабочая программа после успешного запуска сбрасывает счетчик загрузок. 2) Стартует сначала резервная прошивка, в FSBL делается проверка счетчика загрузок, если он меньше N, то: 2.1) счетчик инкрементируется, в MultiBootReg записывается адрес рабочей прошивки (ну, или просто инкремент), делается soft reset, грузится рабочая прошивка. 2.2) иначе ничего не делается, продолжается загрузка резервной прошивки. Счетчик может храниться в специально выделенном разделе FLASH. В моём случае самая обидная ситуация - залить прошивку с нерабочим Ethernet. Используется FreeRTOS и при обновлении hdf-файла настройки bsp всё время сбрасываются. Если не проконтролировать, высока вероятность получить нерабочее устройство. Хороший вариант со счётчиком загрузок, вообще думали в новой версии железа вытащить порт процессора, по которому загрузчик определял бы рабочий или аварийный режим запуска. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dvorkin 1 2 марта, 2020 Опубликовано 2 марта, 2020 · Жалоба On 2/17/2020 at 1:36 PM, doom13 said: On 2/17/2020 at 1:36 PM, doom13 said: Хороший вариант со счётчиком загрузок, вообще думали в новой версии железа вытащить порт процессора, по которому загрузчик определял бы рабочий или аварийный режим запуска. Все это хорошо было в Zynq. А вот в ZynqMP Ultrascale размер FSBL ограничен, часть OCM отдана под FSBL, часть под ATF. Сильно не разгуляешься... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 2 марта, 2020 Опубликовано 2 марта, 2020 · Жалоба 1 hour ago, Dvorkin said: Все это хорошо было в Zynq. А вот в ZynqMP Ultrascale размер FSBL ограничен, часть OCM отдана под FSBL, часть под ATF. Сильно не разгуляешься... Так для анализа состояния пина много кода и не потребуется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dvorkin 1 3 марта, 2020 Опубликовано 3 марта, 2020 · Жалоба Ну, если все так просто - то конечно. У меня малость сложнее. Хотел встроить свой код в U-boot, да не получается... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 3 марта, 2020 Опубликовано 3 марта, 2020 · Жалоба On 3/2/2020 at 10:57 AM, Dvorkin said: Все это хорошо было в Zynq. А вот в ZynqMP Ultrascale размер FSBL ограничен, часть OCM отдана под FSBL, часть под ATF. Сильно не разгуляешься... Ну это смотря как гулять. Я вот без особых проблем затолкал в FSBL инициализацию клок-контроллера и АЦП... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться