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

15 minutes ago, aaarrr said:

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

так скомпилировалось. Можете проговорить что сделали?

 

11 minutes ago, Arlleex said:

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

делаем в коде или оставить как есть пока?

18 minutes ago, Arlleex said:

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

с полуслова не понимаю. Разверните полностью мысль пож-ста )

[Arlleex 131]

9 минут назад, Метценгерштейн сказал:

делаем в коде или оставить как есть пока?

Как хотите.

Я лишь привел пример, в котором ни компилятор, ни линкер никогда не выкинет из образа fw_hash, даже если к нему нет явных обращений.

Ну и чтобы с галкой LTO проект собирался. Без нее не соберется. Вернее соберется не правильно.

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

1 minute ago, Arlleex said:

Как хотите.

Я лишь привел пример, в котором ни компилятор, ни линкер никогда не выкинет из образа fw_hash, даже если к нему нет явных обращений.

Ну и чтобы с галкой LTO проект собирался. Без нее не соберется. Вернее соберется не правильно.

вот пока массив в файле hash.c
 

volatile const unsigned char fw_hash[32] = { 0 };  

Вы предлагаете как его дополнить? 
 

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

это куда дописать?
Дико извиняюсь за свою безграмотность, не сталкивался никогда с этими скатерами и секциями.

А сам скаттер оставить как коллега aaarrr предложил?

4 minutes ago, Arlleex said:

Ну и чтобы с галкой LTO проект собирался. Без нее не соберется. Вернее соберется не правильно.

это что за галка?

[aaarrr 63]

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

Можете проговорить что сделали?

Поместили секции файла hash.c в конец региона загрузки.

 

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

это куда дописать?

Это атрибуты для переменной, содержащей хеш. В этом случае не обязательно будет укладывать её в отдельный файл. В скрипте линкера:

ER_IROM2 +0 {
    * (hash_section)
}

 

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

Все, понял.

Делаю отдельный файл, там

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 предложил? Или не знаю

[Arlleex 131]

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 лег в конце образа прошивки, прямо за последними данными/кодом программы

Цитата

Image Symbol Table

    Local Symbols

    Symbol Name                              Value     Ov Type        Size  Object(Section)

    ....
    [Anonymous Symbol]                       0x08003118   Section        0  main.o(.text.main)
    __arm_cp.0_0                             0x0800314c   Number         4  main.o(.text.main)
    _ZL7fw_hash                              0x08003170   Data          64  main.o(hash_section)
    __tagsym$$used.0                         0x08003170   Number         0  main.o(hash_section)
    _ZN6nsBootL8BootInfoE                    0x200000b4   Data          12  boot.o(.bss.bootInfo)
    [Anonymous Symbol]                       0x200000b4   Section        0  boot.o(.bss.bootInfo)
    .bss                                     0x200000c8   Section       96  libspace.o(.bss)
    ...

Memory Map of the image

  Image Entry point : 0x080020bd

  Load Region LOAD (Base: 0x08002000, Size: 0x000011b8, Max: 0x0000e000, ABSOLUTE)

    Execution Region ROOT (Exec base: 0x08002000, Load base: 0x08002000, Size: 0x000011b0, Max: 0x0000e000, ABSOLUTE)

    Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x08002000   0x08002000   0x000000bc   Data   RO          145    RESET               startup.o
    ...
    0x08003170   0x08003170   0x00000040   Data   RO            4    hash_section        main.o

Убираю 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)
    }
}

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

10 minutes ago, Arlleex said:

В любом исходном .c-файле в глобальной области

что-то на ровном месте

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));

не оборачивая в структуру, т.о. можно использовать тоже?

[Arlleex 131]

Да, я пропустил, для Си тут надо дописать struct. Ну или typedef struct {... } hash_type_t; описать.

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

2 minutes ago, Arlleex said:

Да, я пропустил, для Си тут надо дописать struct. Ну или typedef struct {... } hash_type_t; описать.

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.

и последняя строчка бинарника прошивки

Я к тому, что в конец разместили массив, но он почти в конце, не в самом.

[Arlleex 131]

С чего она у вас в RW-области оказалась? Я проверил - мой пример размещает структуру/массив в конце бинарника, но если размер бинарника не кратен 4 байтам, он добивается нулями в конце.

Если надо чтоб не добивалось - надо читать мануал, как сделать так.

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

const volatile unsigned char fw_hash[32] = {45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45};

static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used));

Как инициализировать чем-то этот конст массив?

давайте его '-' заинитим, покажу конец прошивального бинарника, увидим, что эти черточки не в самом конце файла будут

[Arlleex 131]

2 минуты назад, Метценгерштейн сказал:

const volatile unsigned char fw_hash[32] = {45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45};

static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used));

Как инициализировать чем-то этот конст массив?

давайте его '-' заинитим, покажу конец прошивального бинарника, увидим, что эти черточки не в самом конце файла будут

Потом программа чуть разрастется и в конце добавится паддинг, создавая впечатление, что массив размещен не последним.

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

пока вопрос простой- я разве не могу const массив сразу значениями инитить? Вроде можно

Паддинг и добавляется. Уже есть. Это меня и смущает. Пока хочу в тексте редактора визуально видеть размещение массива.

надо так инициализировать:

const volatile unsigned char fw_hash[32];

static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used)) = {94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94};

94- это '^'

вот где этот массив.

А хочу в самый низ.

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

надо так инициализировать:

const volatile unsigned char fw_hash[32];

static unsigned char const volatile fw_hash[32] __attribute__((section("hash_section"), used)) = {94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94,94};

94- это '^'

вот где этот массив.

А хочу в самый низ.

 

По идее, это последний массив. По мап файлу. Но почему RAM область лезет в бинарь прошивки?

[aaarrr 63]

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

Но почему RAM область лезет в бинарь прошивки?

Потому что содержимое hash.o волшебным образом превратилось в RW.

 

Смешно, но это оно на volatile так реагирует.