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 юзал по минимуму.

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

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