Мне надо расположить прошивку в нижней и верхней части флеша, с пустым местом посередине.
Оптимально - чтобы было занято нижние 4к и столько, сколько нужно - сверху.
Но в принципе пойдет и указать размер верхнего сегмента руками.

Пробовал так:


Ругается section `.text' will not fit in region `rom1'.

Понятно, что можно руками распихать разные файлы по разным секциям, но нет ли способа сделать это автоматически?

Судя по вот этому http://sourceware.org/ml/binutils/2002-11/msg00066.html, так сделать не получится. А жаль. В иаровском линкере никаких проблем с этим не было...

В Makefile

В программе

Таким макаром можно зарезервировать место во флеше и проинитить его нужными данными.
Я так делал для резервирования места в конце флеша, но думаю, что это должно сработать и с любым другим местом (я не проверял).

PS: проверил - не работает
Ругается что на .text налезает...

Да, линкер какой-то недоделанный

Вроде и мощный и выражения там есть, а каких-то тривиальных вещей не сделаешь...

С линкером все в порядке, просто постановка задачи достаточно странная.

Постановка нормальная. Задачи бывают разные. У больших MSP430, например, область векторов прибита гвоздями посреди флеша. Или я хочу, чтобы сегменты стека при размещении "прижимались" к концу, а не началу региона. Желание вполне естественное, а линкер такого не позволяет. А ИАР позволял.

У нас примерно так и сделано, и все работает. Единственно, __attribute__((section(".section_my"))) стоит в конце, после определения переменной.
используем GNU ARM, и компилятор, и линковщик

Так и у меня всё работает, пока объём секции .text не превышает объёма N, где N-это стартовый адрес секции .section_my.
Поэтому я свою секцию .section_my прижимаю к концу флэша. Стоит её передвинуть поближе к началу чтобы она была окружена секцией .text как кердык и случается.

Расширенно задача звучит так:
Есть STM32F10xx, в которых загрузчик должен начинаться с начала флеша (так как первые 4к автоматом защищаются от записи при установке защиты на чтение).

Но загрузчик в 4к не влезает, к тому ж он может впоследствии улучшаться (и увеличиваться в размере).
Поэтому фиксировать под него скажем первые 8к флеша неохота.
Идея такая - загрузчик занимает первые 4 к, затем располагается прошивка (всегда по фиксированному адресу 08001000), а затем в верхней области флеша продолжается загрузчик.

Если впоследствии загрузчик вырастет, можно будет взять новый загрузчик и слить со старой прошивкой, не перекомпиливая ее. Ну а если прошивка не помещается в "дырку" - сливатель выдаст ошибку.

Была кстати идея слинковать снача без дырки, затем вычитать из elf размеры всех функций, сгенерить нужный скрипт для линкера (указав порядок размещения функций) и слинковать заново

Непомнящий Евгений,
я так понял, с дыркой собирается именно загрузчик, грузится во флеш, а потом основная прошивка как-то отдельно догружается? Или после смены загрузчика перекомпилируются только его файлы, а линкуется все вместе с основной прошивкой (которая не перекомпилируется при этом)?

Ну то есть в любом случае размер основной программы известен заранее, ну и значит положение дырки и размер секции text тоже известен. А для высоких адресов загрузчика создаем отдельную секцию и располагаем ее по заданному адресу. И двигаем этот адрес вниз по мере роста загрузчика

Или я что-то не понял?

Сообщение отредактировал IgorKossak - Aug 16 2012, 18:25

Все так, но как это сделать? Пока единственный рабочий вариант - руками указывать, какие входные секции куда размещаются, что тоскливо.

Мое предложение - сделать это первичным и вторичным загрузчиком. Первичный никогда не стирается и всегда занимает меньше 4 к. Основная его задача - инициализация железа и запуск вторичного загрузчика (возможно, обновление себя и вторичного загрузчика). Точка входа во вторичный загрузчик располагается по фиксированному адресу.

радикальная идея.

Минусы:
1. надо поместиться в т.ч. в младшие модели с 16к флеши. т.е. общий размер загрузчика не более 8 к. В 8 к у меня с трудом уместился загрузчик без всякого разделения на части
2. усложняются процессы сборки образа и перепрошивки
3. функциональность не делится на две независимые части. А если принудительно поделить - сильно вырастет размер.

1. Зачем? Фиксированный адрес джампа, а где будет находиться основной загрузчик - пофигу.
2. Да ладно. Один раз скрипт накататься
3. В том то и суть, что делится. Плюсом, можно вынести работу с железом в первичный загрузчик, а вторичный сделать аппаратно-независимым, только дергать логические функции.

Я подобные схемы очень часто видел в прошивках тех же сотовых телефонов - абстракция протокола загрузчика + защита от взлома через подмену вторичного загрузчика.

8к. У Вас там цифровая подпись что-ли?

Тогда плиз напишите поподробнее.
Вот у меня загрузчик.
Его задачи:
1. Ловить байты (работа с железом)
2. Складывать из них пакеты
3. Парсить пакеты, формировать ответы
4. Передавать байты (снова работа с железом)
5. Формировать по мере принятия пакетов образ программы, дешифровать его и программировать флеш
6. По команде извне вычитать программу из устройства - считать из флеша, зашифровать, оформить в пакеты

Как его разделить на две независимые части?
Задачи 1-5 должны присутствовать уже в первой части загрузчика - иначе он не сможет запрограммировать второй загрузчик.
Задача 6 сама по себе весит немного...