gnu ld - как сделать "дырку" в памяти Опции

[Непомнящий Евген...]

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

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

Код

MEMORY
{  
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x0000C000
  rom1 (rx)  : ORIGIN = 0x08000000, LENGTH = 0x00001000
  rom2 (rx)  : ORIGIN = 0x08000000 + 0x00040000 - 0x0001000, LENGTH = 0x00001000
}

SECTIONS
{
    .text :
    {  
        KEEP(*(.vectors))
        *(.text .text.*)                           
        *(.rodata)                                               
    } > rom1    

    .text2 :
    {        
        *(.text .text.*)                           
        *(.rodata)                                               
    } > rom2
  
   ...
}

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

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

[MBR]

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

Кстати, вторичный загрузчик, вообще можно не держать во флеше. Грузить непосредственно первичным в ram и стартовать оттуда. Решает кучу проблем.

[Непомнящий Евген...]

Обычно у первичного загрузчика свой протокол, у вторичного - поверх первичного - свой.

А зачем второму свой протокол?

Есть таблица вызова функций для работы с железом.

В смысле - вторичный загрузчик дергает по этой таблице функции из первичного?

Первичный загрузчик гарантирует доставку пакетов, вторичный - занимается логикой.

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

Кстати, вторичный загрузчик, вообще можно не держать во флеше. Грузить непосредственно первичным в ram и стартовать оттуда. Решает кучу проблем.

А каких? Вроде с флешем только одна проблема - во время записи флеша проц "виснет". При стирании страницы получается ощутимо.

[MBR]

А зачем второму свой протокол?

Как зачем? Первичный - пакет принял, пакет отправил. Проконтролировал отправку контрольными суммами, если нужно, переслал. Что находится в пакете - ему знать не нужно, он лишь гарантированно доставляет данные, устраняя вероятные ошибки в физическом канале связи. Вторичный - парсит пакеты без траспортных заголовков, определяет, какая там логическая команда, какие данные и занимается непосредственно логикой. OSI же.

В смысле - вторичный загрузчик дергает по этой таблице функции из первичного?

Да. Набор этих функций минимален, и, скорее всего, не будет нуждаться в доработке.

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

Надо исходить из того, что основные задачи первичного загрузчика:
- транспортный канал с хостом
- загрузка вторичного загрузчика через канал связи
- обеспечить проверку подлинности и запуск вторичного загрузчика.
- запустить основную прошивку, если условия запуска загрузчика не выполнены
Все это занимает меньше килобайта.

А каких? Вроде с флешем только одна проблема - во время записи флеша проц "виснет". При стирании страницы получается ощутимо.

Главное: не нужно поддерживать на уровне хоста зоопарк версий. Прогрузили вторичный загрузчик, запустили - вот и новый протокол. Можно их делать несколько - для каждой задачи - прошивка основного флеша, прошивка датафлеш. Да хоть сброс настроек.

[Непомнящий Евген...]

Как зачем? Первичный - пакет принял, пакет отправил. Проконтролировал отправку контрольными суммами, если нужно, переслал. Что находится в пакете - ему знать не нужно, он лишь гарантированно доставляет данные, устраняя вероятные ошибки в физическом канале связи. Вторичный - парсит пакеты без траспортных заголовков, определяет, какая там логическая команда, какие данные и занимается непосредственно логикой. OSI же.

Если первому загрузчику надо заливать второй, то так не получится - ему придется парсить пакеты и отвечать на них... А заливка второго загрузчика ничем не отличается от заливки самой программы (по крайней мере в моем случае, когда прога живет во встроенном флеше). Так что опять получается, что в первом загрузчике сидит все, а во втором - почти ничего

Надо исходить из того, что основные задачи первичного загрузчика:
- транспортный канал с хостом
- загрузка вторичного загрузчика через канал связи
- обеспечить проверку подлинности и запуск вторичного загрузчика.
- запустить основную прошивку, если условия запуска загрузчика не выполнены
Все это занимает меньше килобайта.

Ну хз насчет килобайта. У меня практически эта функциональность + шифрование + еще кое-что по мелочи едва влезла в 8 к. Компилятор gnu gcc от бывшего кодесоурсери. Писал на С с классами, без всяких наворотов, CMSIS юзал по минимуму.

Главное: не нужно поддерживать на уровне хоста зоопарк версий. Прогрузили вторичный загрузчик, запустили - вот и новый протокол. Можно их делать несколько - для каждой задачи - прошивка основного флеша, прошивка датафлеш. Да хоть сброс настроек.

А зачем нам новый протокол? Опять таки, функциональность устройства по железу фиксирована на момент заливки туда основного загрузчика. Т.е. если в основном загрузчике иметь разные варианты компиляции в зависимости от устройства - это с головой хватит.

[_Артём_]

Ну хз насчет килобайта. У меня практически эта функциональность + шифрование + еще кое-что по мелочи едва влезла в 8 к. Компилятор gnu gcc от бывшего кодесоурсери. Писал на С с классами, без всяких наворотов, CMSIS юзал по минимуму.

Что-то многовато. Ищи там ФУНКЦИОНАЛ навороченный?
На АВР приём-передача по UART-запись-чтение прошивки в dataflash-простейшее шифрование в 4КБ влезало. В 8 наверное AES влезет и приём-передача через GSM например (GSM не проверял).

[Непомнящий Евген...]

Что-то многовато. Ищи там ФУНКЦИОНАЛ навороченный?
На АВР приём-передача по UART-запись-чтение прошивки в dataflash-простейшее шифрование в 4КБ влезало. В 8 наверное AES влезет и приём-передача через GSM например (GSM не проверял).

IAR AVR как-то получше оптимизировал. На нем в 8К помимо того, что влезло в АРМ, втиснулась еще и индикация на дисплее. Шифрование у нас ГОСТ, прием-передача конкретно в этом случае по самодельному интерфейсу, чем-то похожему на SPI.

Функционал:
1. Запись прошивки (+ проверка на совместимость + дешифровка + проверка цифровой подписи)
2. Чтение прошивки (+ шифровка, цифровая подпись)
3. Чтение информации об устройстве и статуса
4. Широковещательная запись (похожа на 1, но немного другой алгоритм)
5. Всякие мелочи - запуск программы, принудительный переход в программирование

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

Писал на С с классами (просто данные и методы собирал в класс). АСМ не юзал.

Там пакета-то - код команды, блок данных, crc. Ответ ack/nack. Это 5 строчек на сях. Получить блок, проверить crc, скопировать в область памяти, увеличить счетчик. По команде запуска джампнуть на адрес. И 3 команды в минимуме - handshake + load secondary, read/write.

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

Имхо, си c классами в загрузчике, это слишком жирно.

Ну может быть. С другой стороны, чем это сильно отличается от функций + глобальных переменных? Единственное отличие - каждая функция получает доп указатель. Но у СТМ по идее тут должно быть все хорошо. Хотя надо ради интереса один класс сделать на статических переменных\функциях, возможно действительно что-то ужмется.

Баги, новые команды. Да что угодно. Если устройств выпустится достаточное количество, поддерживать их будет уже геморно.

Баги и новые команды сидят в самой прошивке. Если они вдруг поселятся в первичном загручике - все равно его перепрошить не получится...