[aaarrr 63]

14 minutes ago, Метценгерштейн said:

Скрипт линкера- это .sct файл?

Да, .sct

 

22 minutes ago, Метценгерштейн said:

можно попросить раскрыть подробности?

Можно, например, определить массив под хеш и средствами линкера закинуть его в конец загрузочного региона (+LAST).

[Метценгерштейн 0]

3 minutes ago, aaarrr said:

Да, .sct

 

Можно, например, определить массив под хеш и средствами линкера закинуть его в конец загрузочного региона (+LAST).

Если так можно, то это решит вопрос.
Проговорим- массив в коде объявлен, объявление участвует в хешировании. Но содержимое его никак не влият на хеш. Только если можно, попрошу пример как это делается.

Тогда можно самой прошивкой себя обсчитывать и записывать в этот массив. Но пока как-то расплывчато все равно.

[Метценгерштейн 0]

Наверное, нужен др подход. Я чуть может ввел в заблужение. Еще раз. Прошивка заканчивается 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]

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]

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]

4 minutes ago, Метценгерштейн said:

Объявили массив типа hash_type_t, можем и int.
Где гарантия что он прямо к концу кода запишется?

Его не просто так объявили, это единственный объект в файле hash.c; далее hash.c превратится после компиляции в hash.o, содержимое которого будет расположено в конце загрузочного региона (hash.o (*, +Last)). Можно и не городить отдельный файл, тогда нужно поместить переменную в отдельную секцию через #pragma arm section с соответствующими поправками в .sct

[x893 35]

7 minutes ago, Метценгерштейн said:

Спасибо. 
Давайте проговорим.

Объявили массив типа hash_type_t, можем и int.
Где гарантия что он прямо к концу кода запишется? 
И второе, в скатере добавили 

hash.o (*, +Last)

это же не наш этот массив. 
В общем, логику пока не пойму.
Спасибо что помогаете- тут не так все просто с этой задачей))

Добавьте __attribute__((section(...)))

Даже обсуждать тут нечего. Выше всё написал модератор.

[Метценгерштейн 0]

3 minutes ago, aaarrr said:

Его не просто так объявили, это единственный объект в файле hash.c; далее hash.c превратится после компиляции в hash.o, содержимое которого будет расположено в конце загрузочного региона (hash.o (*, +Last)). Можно и не городить отдельный файл, тогда нужно поместить переменную в отдельную секцию через #pragma arm section с соответствующими поправками в .sct

Вырисовывется теперь картина. А тип данных int , к примеру, может быть же? 

hash.o (*, +Last)

это именно к концу его добавляет? Такой синтаксис

[aaarrr 63]

2 minutes ago, Метценгерштейн said:

А тип данных int , к примеру, может быть же?

Может, но объявлять нужно именно как volatile const - это важно.

 

3 minutes ago, Метценгерштейн said:

это именно к концу его добавляет? Такой синтаксис

Да, к концу.

[Метценгерштейн 0]

пробуем. Отпишусь. Не быстро будет.

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]

17 minutes ago, Метценгерштейн said:

ошибка компиляции, что там регионы RAM заезжают друг на друга. Именно RAM. По мап файлу, RAM следаом за флеш идет размещение.

Текст ошибки и map файл приведите.

[Метценгерштейн 0]

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]

Угу. Немного не так надо было:

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]

3 minutes ago, aaarrr said:

Угу. Немного не так надо было:

Можете проговорить? Почему угу? )

Я вижу, что есть прошивка опред. размера. Я вижу, что по мапу она короче на 0x170 байт почему- то. И сразу в тот регион лезет РАМ данные. Больше сложно мне понять 

[Arlleex 131]

7 минут назад, aaarrr сказал:

Тут уже и +Last не особо нужен, но пусть будет.

Тогда лучше *.o (hash_section, +Last), чтобы сборка под LTO не выругалась.

Ну а к строчке в коде добавить атрибут размещения и использования

hash_type_t const volatile fw_hash __attribute__((section(hash_section), used));