aaarrr 63 28 марта Опубликовано 28 марта · Жалоба 14 minutes ago, Метценгерштейн said: Скрипт линкера- это .sct файл? Да, .sct 22 minutes ago, Метценгерштейн said: можно попросить раскрыть подробности? Можно, например, определить массив под хеш и средствами линкера закинуть его в конец загрузочного региона (+LAST). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 28 марта Опубликовано 28 марта · Жалоба 3 minutes ago, aaarrr said: Да, .sct Можно, например, определить массив под хеш и средствами линкера закинуть его в конец загрузочного региона (+LAST). Если так можно, то это решит вопрос. Проговорим- массив в коде объявлен, объявление участвует в хешировании. Но содержимое его никак не влият на хеш. Только если можно, попрошу пример как это делается. Тогда можно самой прошивкой себя обсчитывать и записывать в этот массив. Но пока как-то расплывчато все равно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 28 марта Опубликовано 28 марта · Жалоба Наверное, нужен др подход. Я чуть может ввел в заблужение. Еще раз. Прошивка заканчивается 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- идет ошибка, то что-то там с ОЗУ не то будет, данные потеряются. В общем, пока не очень понятно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 28 марта Опубликовано 28 марта · Жалоба hash.c volatile const hash_type_t fw_hash = { 0 }; .sct: 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 .ANY (+RW +ZI) } } В программе считаем хеш от начала (Load...Base) до &fw_hash, сравниваем с fw_hash. Внешней утилитой перезаписываем последние sizeof(hash_type_t) байт прошивки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 14 hours ago, aaarrr said: В программе считаем хеш от начала (Load...Base) до &fw_hash, сравниваем с fw_hash. Внешней утилитой перезаписываем последние sizeof(hash_type_t) байт прошивки. Спасибо. Давайте проговорим. 14 hours ago, aaarrr said: volatile const hash_type_t fw_hash = { 0 }; Объявили массив типа hash_type_t, можем и int. Где гарантия что он прямо к концу кода запишется? И второе, в скатере добавили hash.o (*, +Last) это же не наш этот массив. В общем, логику пока не пойму. Спасибо что помогаете- тут не так все просто с этой задачей)) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба 4 minutes ago, Метценгерштейн said: Объявили массив типа hash_type_t, можем и int. Где гарантия что он прямо к концу кода запишется? Его не просто так объявили, это единственный объект в файле hash.c; далее hash.c превратится после компиляции в hash.o, содержимое которого будет расположено в конце загрузочного региона (hash.o (*, +Last)). Можно и не городить отдельный файл, тогда нужно поместить переменную в отдельную секцию через #pragma arm section с соответствующими поправками в .sct Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 35 29 марта Опубликовано 29 марта · Жалоба 7 minutes ago, Метценгерштейн said: Спасибо. Давайте проговорим. Объявили массив типа hash_type_t, можем и int. Где гарантия что он прямо к концу кода запишется? И второе, в скатере добавили hash.o (*, +Last) это же не наш этот массив. В общем, логику пока не пойму. Спасибо что помогаете- тут не так все просто с этой задачей)) Добавьте __attribute__((section(...))) Даже обсуждать тут нечего. Выше всё написал модератор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 3 minutes ago, aaarrr said: Его не просто так объявили, это единственный объект в файле hash.c; далее hash.c превратится после компиляции в hash.o, содержимое которого будет расположено в конце загрузочного региона (hash.o (*, +Last)). Можно и не городить отдельный файл, тогда нужно поместить переменную в отдельную секцию через #pragma arm section с соответствующими поправками в .sct Вырисовывется теперь картина. А тип данных int , к примеру, может быть же? hash.o (*, +Last) это именно к концу его добавляет? Такой синтаксис Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба 2 minutes ago, Метценгерштейн said: А тип данных int , к примеру, может быть же? Может, но объявлять нужно именно как volatile const - это важно. 3 minutes ago, Метценгерштейн said: это именно к концу его добавляет? Такой синтаксис Да, к концу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба пробуем. Отпишусь. Не быстро будет. 8 minutes ago, aaarrr said: Может, но объявлять нужно именно как volatile const - это важно. объявил в файле 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) может некорректно разместили. Как только комментирую эту строку в скаттере, нет ошибок компиляции. Т.е. массив объявлен корректно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба 17 minutes ago, Метценгерштейн said: ошибка компиляции, что там регионы RAM заезжают друг на друга. Именно RAM. По мап файлу, RAM следаом за флеш идет размещение. Текст ошибки и map файл приведите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 29 марта Опубликовано 29 марта · Жалоба Угу. Немного не так надо было: 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 (было + 0 в оригинале) .ANY (+RW +ZI) } ER_IROM2 +0 { hash.o (*, +Last) } } Тут уже и +Last не особо нужен, но пусть будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 29 марта Опубликовано 29 марта · Жалоба 3 minutes ago, aaarrr said: Угу. Немного не так надо было: Можете проговорить? Почему угу? ) Я вижу, что есть прошивка опред. размера. Я вижу, что по мапу она короче на 0x170 байт почему- то. И сразу в тот регион лезет РАМ данные. Больше сложно мне понять Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 29 марта Опубликовано 29 марта · Жалоба 7 минут назад, aaarrr сказал: Тут уже и +Last не особо нужен, но пусть будет. Тогда лучше *.o (hash_section, +Last), чтобы сборка под LTO не выругалась. Ну а к строчке в коде добавить атрибут размещения и использования hash_type_t const volatile fw_hash __attribute__((section(hash_section), used)); Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться