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

Метценгерштейн

Свой
  • Постов

    1 573
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Метценгерштейн

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

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

6 155 просмотров профиля
  1. const volatile unsigned char fw_hash[32]; static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used)); это без обрамления в структуру. И мап: 0x0001dff4 0x0001dff4 0x00000030 Data RO 1202 Region$$Table anon$$obj.o 0x0001e024 0x0001e024 0x00000020 Data RW 683 hash_section hash.o Execution Region RW_RAM1 (Exec base: 0x0001e044, Load base: 0x0001e044, Size: 0x00075014, Max: 0xffffffff, ABSOLUTE, COMPRESSED[0x0000016c]) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x0001e044 COMPRESSED 0x00000018 Data RW 3 .data heap_2.o 0x0001e05c COMPRESSED 0x00000004 Data RW 55 .data port.o к 0x0001e024 прибавить размер 0x20- нашего массива, как раз получаемначало 0x0001e044 Другми словами, работает. Спасибо, парни! В принципе, если рекомендаций нет больше, то все) с прошивкой не то все равно еще. Ее размер не заканчивается на 0x0001e044, а размер прошивки 0x0001E1B0. и последняя строчка бинарника прошивки Я к тому, что в конец разместили массив, но он почти в конце, не в самом.
  2. что-то на ровном месте static struct hash_type_t const volatile fw_hash __attribute__((section("hash_section"), used)); это не испорт же итог? const volatile unsigned char fw_hash[32]; static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used)); не оборачивая в структуру, т.о. можно использовать тоже?
  3. Все, понял. Делаю отдельный файл, там volatile const unsigned char fw_hash[32] = { 0 }; и скатер добавляю ER_IROM2 +0 { hash.o (*, +Last) } надежно и понятно. Спасибо. Отпишусь если что вдруг пойдет не так ) 0x0001df5b 0x0001df5b 0x00000001 PAD 0x0001df5c 0x0001df5c 0x00000095 Data RO 434 .conststring support.o 0x0001dff1 0x0001dff1 0x00000003 PAD 0x0001dff4 0x0001dff4 0x00000040 Data RO 1200 Region$$Table anon$$obj.o Execution Region RW_RAM1 (Exec base: 0x0001e034, Load base: 0x0001e034, Size: 0x00075024, Max: 0xffffffff, ABSOLUTE, COMPRESSED[0x00000170]) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x0001e034 COMPRESSED 0x00000018 Data RW 3 .data heap_2.o 0x0001e04c COMPRESSED 0x00000004 Data RW 55 .data port.o что-то не пояился в мапе наш hash.o файл может не сработала строчка в скатере? Может пойти по пути, что Arlleex предложил? Или не знаю
  4. вот пока массив в файле hash.c volatile const unsigned char fw_hash[32] = { 0 }; Вы предлагаете как его дополнить? hash_type_t const volatile fw_hash __attribute__((section(hash_section), used)); это куда дописать? Дико извиняюсь за свою безграмотность, не сталкивался никогда с этими скатерами и секциями. А сам скаттер оставить как коллега aaarrr предложил? это что за галка?
  5. так скомпилировалось. Можете проговорить что сделали? делаем в коде или оставить как есть пока? с полуслова не понимаю. Разверните полностью мысль пож-ста )
  6. Можете проговорить? Почему угу? ) Я вижу, что есть прошивка опред. размера. Я вижу, что по мапу она короче на 0x170 байт почему- то. И сразу в тот регион лезет РАМ данные. Больше сложно мне понять
  7. Error: L6788E: Scatter-loading of execution region RW_RAM1 to execution address [0x0001e024,0x0001e58c) will cause the contents of execution region RW_RAM1 at load-address [0x0001e004,0x0001e174) to be corrupted at run-time. ============================================================================== Memory Map of the image Image Entry point : 0x00000000 Load Region LR_IROM1 (Base: 0x00000000, Size: 0x0001e56c, Max: 0xffffffff, ABSOLUTE, COMPRESSED[0x0001e174]) Execution Region ER_IROM1 (Exec base: 0x00000000, Load base: 0x00000000, Size: 0x0001e024, Max: 0xffffffff, ABSOLUTE) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x00000000 0x00000000 0x000000fc Code RO 690 * NUC_INIT startup.o 0x000000fc 0x000000fc 0x00000008 Code RO 974 * !!!main c_5.l(__main.o) 0x00000104 0x00000104 0x0000003c Code RO 1204 !!!scatter c_5.l(__scatter.o) ... ... ... и конец его 0x0001dfd1 0x0001dfd1 0x00000003 PAD 0x0001dfd4 0x0001dfd4 0x00000030 Data RO 1200 Region$$Table anon$$obj.o 0x0001e004 - 0x00000020 Zero RW 683 .bss hash.o Execution Region RW_RAM1 (Exec base: 0x0001e024, Load base: 0x0001e004, Size: 0x00075034, Max: 0xffffffff, ABSOLUTE, COMPRESSED[0x00000170]) Exec Addr Load Addr Size Type Attr Idx E Section Name Object 0x0001e024 COMPRESSED 0x00000018 Data RW 3 .data heap_2.o 0x0001e03c COMPRESSED 0x00000004 Data RW 55 .data port.o
  8. пробуем. Отпишусь. Не быстро будет. объявил в файле hash.c volatile const unsigned char fw_hash[32] = { 0 }; единственное, размер 32 задал. При скатере LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) hash.o (*, +Last) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 (было + 0 в оригинале) .ANY (+RW +ZI) } } ошибка компиляции, что там регионы RAM заезжают друг на друга. Именно RAM. По мап файлу, RAM следаом за флеш идет размещение. Другими словами, hash.o (*, +Last) может некорректно разместили. Как только комментирую эту строку в скаттере, нет ошибок компиляции. Т.е. массив объявлен корректно
  9. Вырисовывется теперь картина. А тип данных int , к примеру, может быть же? hash.o (*, +Last) это именно к концу его добавляет? Такой синтаксис
  10. Спасибо. Давайте проговорим. Объявили массив типа hash_type_t, можем и int. Где гарантия что он прямо к концу кода запишется? И второе, в скатере добавили hash.o (*, +Last) это же не наш этот массив. В общем, логику пока не пойму. Спасибо что помогаете- тут не так все просто с этой задачей))
  11. Наверное, нужен др подход. Я чуть может ввел в заблужение. Еще раз. Прошивка заканчивается 0x0001e194 - 1 И я хочу внешним софтом положить к концу ее некий кусок данных. Потом считать его самой прошивкой. И вот мап, где ОЗУ существенно залезает аж внутрь флеш памяти, соответственно, перетирает записанное мной. Надо скатер может настроить вот он: LR_IROM1 0x00000000 { ; load region size_region ER_IROM1 0x00000000 { ; load address = execution address *.o (NUC_INIT, +First) *(InRoot$$Sections) .ANY (+RO) } RW_RAM1 +0 { ; RW_RAM1 start address is after ER_ROM1 .ANY (+RW +ZI) } } Даже здесь видно что ОЗУ сразу должно идти за флеш, но оно залазит внутрь. Строчка RW_RAM1 +0 замену на RW_RAM1 +32- идет ошибка, то что-то там с ОЗУ не то будет, данные потеряются. В общем, пока не очень понятно
  12. Если так можно, то это решит вопрос. Проговорим- массив в коде объявлен, объявление участвует в хешировании. Но содержимое его никак не влият на хеш. Только если можно, попрошу пример как это делается. Тогда можно самой прошивкой себя обсчитывать и записывать в этот массив. Но пока как-то расплывчато все равно.
  13. можно попросить раскрыть подробности? Скрипт линкера- это .sct файл? Тогда в коде прошивки как это будет выглядеть? Объявляю массив по адресу, что в линкере не учитывается?
  14. Думаем. Решаема. Скорее, надо считать хеш внутри самой прошивки и положить куда-то туда, где он будет вне прошивки. Внешняя флеш- может как вариант. Но как только я объявляю массив с __attribute__ и указывваю на его размещение, не войдет ли этот массив в состав прошивки?
  15. Все равно еще не улавливаю мысли как сделать. есть прошивка от 0 до 0x0001E194 B хэш я считаю именно ее, без таблицы векторов и прочего.
×
×
  • Создать...