Перейти к содержанию
    

Arlleex

Свой
  • Постов

    5 751
  • Зарегистрирован

  • Посещение

  • Победитель дней

    13

Arlleex стал победителем дня 20 марта

Arlleex имел наиболее популярный контент!

Репутация

129 Очень хороший

2 Подписчика

Информация о Arlleex

  • Звание
    Гуру
    Гуру

Контакты

  • ICQ
    Array

Посетители профиля

17 502 просмотра профиля
  1. С чего она у вас в RW-области оказалась? Я проверил - мой пример размещает структуру/массив в конце бинарника, но если размер бинарника не кратен 4 байтам, он добивается нулями в конце. Если надо чтоб не добивалось - надо читать мануал, как сделать так.
  2. Да, я пропустил, для Си тут надо дописать struct. Ну или typedef struct {... } hash_type_t; описать.
  3. LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) *.o (hash_section, +last) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } } В любом исходном .c-файле в глобальной области struct hash_type_t { char buf[64]; }; static hash_type_t const volatile fw_hash __attribute__((section("hash_section"), used)); Смотрим .map, убеждаемся что fw_hash лег в конце образа прошивки, прямо за последними данными/кодом программы Убираю used из списка атрибутов (обращений к fw_hash в программе нет) - ошибка линковки. Ставлю LTO и обзываю строчку main.o (hash_section, +last) и даже возвращаю used в определении fw_hash - ошибка линковки. Все логично. То же самое можно получить чуть другим скаттером LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) } ER_IROM_HASH +0 UNINIT { *.o (hash_section) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } }
  4. Как хотите. Я лишь привел пример, в котором ни компилятор, ни линкер никогда не выкинет из образа fw_hash, даже если к нему нет явных обращений. Ну и чтобы с галкой LTO проект собирался. Без нее не соберется. Вернее соберется не правильно.
  5. Тогда лучше *.o (hash_section, +Last), чтобы сборка под LTO не выругалась. Ну а к строчке в коде добавить атрибут размещения и использования hash_type_t const volatile fw_hash __attribute__((section(hash_section), used));
  6. Вот говорил же, захотелось вам всадить себе пулю в колено, а теперь рубашку на лоскуты режете. У процессора есть 2 внутренних режима: режим потока и режим обработчика прерывания. При входе в прерывание активизируется последний. При выходе из обработчика вы возвращаетесь в режим потока. Предположу, что jcxz имел в виду не тупо переходить на приложение из прерывания, а в прерывании подменить LR/PC/SP фреймстека так, чтобы вернуться в привелегированном режиме потока сразу на приложение.
  7. К аббревиатурам DSP/FPGA/SoC/Real-Time обычно в придачу идет солидная финансовая составляющая и вопрос цены комплектации вторичен.
  8. Тогда задача не решаема. Ибо Вы пытаетесь считать хэш двух разных прошивок - одной с еще неизвестным хэшем, другую - с известным и записанным.
  9. А разница? Хоть 100 байт, если места хватит. Насчет блочных хэшей - тоже не вижу проблемы, т.к. блок добивается нулями как на стороне программы подготовки бинарника, так и на стороне МК при "распаковке". Можно.
  10. Коллега имел в виду вот что Вот Вы скомпилировали свой hex-файл прошивки. В ней так или иначе предусмотрели 2 служебных поля (пока что пустых): Application Size и CRC32. 1. Дальше сторонней утилитой открываете бинарник и записываете в App Size размер файла прошивки (он же размер образа, лежащего во Flash МК потом). 2. Дальше считаете КС от начала до App Size включительно. 3. Дальше считаете КС до конца файла, исключая App CRC32. Полученную КС кладете в App CRC32 и сохраняете бинарник. Теперь при старте МК выполняет штатную процедуру загрузки. МК читает App Size, и точно так же как программа подготовки бинарника считает КС. Сверяет с записанной. Совпало - ок, нет - образ записан криво.
  11. Единым блоком считать КС не получится так. Особенно, если в качестве алгоритма взят CRC.
  12. Ну Вы же сами пишете программу - все от Вас только и зависит. Я после компиляции проекта в 2 зарезервированных места кладу размер прошивки в байтах и контрольную сумму, посчитанную, разумеется, без учета содержимого в контрольной сумме. Написал простейший сишный екзешник, запускаемый либо отдельно, либо прямо IDE-шкой после компиляции. В МК загрузчик знает адреса размера прошивки и контрольной суммы и делает все наоборот: читает размер, проходится по всей прошивке кроме контрольной суммы, контрольную сумму добавляет в конце и должен получиться 0. Ведь никто не мешает КС проверять не единым блоком, а разбитым на несколько отдельных участков памяти.
  13. И размера, и КС. Я кладу в неиспользуемые вектора, либо после таблицы векторов (в разных проектах исторически по-разному).
  14. Думаю, стоит подумать над перемещением размера прошивки с конца куда-нибудь в начало, в известные и неизменные адреса. Завтра прошивка стала занимать больше места и теперь заново искать адрес под размер образа - так себе.
  15. А в чем сложность? Не с позиции дартаньянизма спрашиваю - просто какое-то количество времени назад активно работал с цинком, как раз FreeRTOS-бареметал. SDK дает работающий BSP, не надо курить-настраивать DDR и кэш-регионы (самое сложное для стартапа) - все само "из коробки". При необходимости правится легко. И кстати: раз на цинке меряли задержку: а как меряли? Я лично не проверял (ибо не было нужды), но задержка между активизацией FIQ до смены режима CPU с User на FIQ - мгновенная. uCLinux.
×
×
  • Создать...