Някой знае ли как в линкерския файл да задам да залепи втори елф файл към тоя дето компилирам. Например като компилирам буутлоадер и към него да залепя вече компилиран елф файл с приложението. На фрискелските s08 и s12 контролери става като в линкерския файл просто напиша на един ред HEXFILE filename.s19. Нещо не мога да го намеря из документацията. Страва въпрос за Kinetis ARM-ве и KDS средата, ама предполагам че е същото за всички армове.

Значи въпросът ти е свързан с модела на компилатора, а не толкова с модела на проца...

сега виждам че си писак KDS, макар че май не съм го чувал. Иначе принципно (поне при GCC) елф е изходен формат за линкера и не знам дали може да го приема и като входен. Но не разбирам какъв ти е проблема да добавиш една стъпка в мейкфайла си (стига да не си с auto-нещо си) и да конвертираш elf до бинари и него да го линкнеш. Ако това ти върши работа мога ти кажа стъпките...

С ауто-нещо съм .
Иначе аз го конвертирам елф-а до bin и s19 защото после ми трябват обаче в bin-а запълва неизползваните адреси с FF, демек може да се окаже проблем да се линкне към текущото компилиране. Може би s19 файла да се позлва, защото той съдържа само адресите, които се ползват. Та приложението го имам в елф, bin и s19 и ми е все тая кой от тях ще линквам, стига на края да имам един общ елф или s19, дето да мога да налея в контролера.

Сложна работа са тия ауто-прецакванки... не знам как точно става с тях

Иначе ако трябва да вкарам външни данни (картинки или каквото е там) първо ги правя на бинарен файл. След това с objcopy бинарния файл го конвертирам до обектен файл като евентуално пренабивам секцията. Примерно ей това се инлудва някак си в мейкфайла :



В случая към обектите добавям logo.op файл, какъвто нормално не съществува но има правило за него как се прави... Съответно прави такъв обектен файл и той има някаква секцийка.. След това нормално линкера се вика за всички обектни файлове, включая и logo.op и почва да сглобява. А сглобяването както знаеш е от еди коя си входна секция към еди коя си изходна секция. Демек ако искаш нещо по-специално в линкерския скрипт трябва да му кажеш тая секция къде да отиде...

Нещо много сложно ми се струва, ама ще пробвам да видя какво ще стане .

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

Но доколкото знам аз GCC са доста консвервативно племе и много държат да запазят съвместимост с ерата на динозаврите и затова избягват всякаква конкретика. Не може през сорса да управляваш адреси и т.н., само през линкера, пък той разбира само от секции, а пък секции имаш само в обектни файлове... та затова ползвам тоя трик с минаването през обектен файл

А на теб резултата (слепения) фаил за дебъгване ли ти трябва или за крайно програмиране. Ако е второто - прави ги на hex, bin и ги лепи после с нещо външно, това е лесно. Ако е за дебъгване, вече наистина трябва да лепиш elf, а това ми се струва кошмарец.

Само за програмиране и май наистина просто ще залепя s19 файловете. Направо не мога да повярвам, че няма лесен начин това да стане с компилатора или линкера .

ми то реално ти трябва да билднеш бинарен имидж, което си става с проста команда copy

дори да имаш другия случай - буут лоудър и кернер, пак става с копи команда, защото двете части си живеят в различен свят и се дебъгват поотделно.
защо да тормозиш линкера, когато двете не част от едно цяло?

Щото така бях свикнал до сега .

За сега се задоволявам с ей това тулче дето просто слепя s19 файлове:
http://mcuoneclipse.com/2016/02/26/merging-s19-files/

Пробвам да кодирам файла с фърмуера, дето се ъпдейтва от бутлоадера ама много бавно се декорира - това с AES256 на Кортекс М0. 512 байта за около секунда. Вие какво ползвате (ако въобще кодирате ъпдейт файла), дето да е по-бързо?

Аз съм с AES192 обикновено, ама доколкото помня ти май имаше изискване за 256...

Но не това е важното, мисля че времената между 192 и 256 не бяха толкова фрапиращи. Казвам съм и преди, че AES е алгоритъма при който стават най-яките осирания. Има два проблема, първия естествено е че за скорост трябва целия шифт регистър да се събере в регистри, а компилаторите го изпускат тоя момент. Втория е ако ползваш сорс оптимизиран за x86 е те тогава може яко да се издъни, особено ако ползват long шифтвания и т.н. дето на PC стават за 1 клок а при АРМ поне GCC ги прави с викане на интрисик функция и всичко отива в киреча...

С две думи, ако имаш различни С-сорсове пробвай и или поне разгледай кви ги вършат и най-добрия вариант - асемблер брат.... Може да вземеш моя код М3 и да се опиташ да го преправиш за М0, мися че само определени интрукции дето ги няма трябва да се сменят. После може да ми го върнеш та си имам порт и за М0

256 е с около 17% по-бавно от 192.
Много таблици и оптимизация му е майката. Мъгливите ми спомени са за грубо около 700 цикъла на блок за 128 на ARM7TDMI в 32-битов режим, т.е. около 1MB/sec на < 50MHz клок.

Миро, ползвам готов опън сорс код за М0 на един пич (ще пусна линк по-късно) и няма асемблер, щото същия код го ползвам и в рс програмата дето прави файла. Не знам колко е оптимизиран но времената за ъпдейт са следните - за файл 12.5к без кодиране времето за ъпдейт е 5.5 сек, а с кодиране около 28 сек. (това с изпращането на файла през CAN бъса), демек ако отида на максималната големина за приложението ми, която теоретично е около 80к ще отнеме около 3-4 мин да го ъпдейтна. На мен ми се иска да стане за под минута. Нямам изискване за аес256 (аз си ги пиша изискванията), но дори да слезна и на аес128 пак няма да падне много. Отделно това трябва да го подкараме и на някои 16 битови контролери и там какво ще стане не ми се мисли .
С най-голямо удоволствие бих ти преправил кода, ама нямам време да го правя за тоя проект. Имам обаче едни библиотеки от фрискейл, които са на асемблер, но не съм ги пробвал още щото исках да ползвам един и същи код в контролера и на рс-то, за да не настъпвам излишни мотики. Колко мислиш, че може да падне ако е на асемблер? Елиптик кървс криптирането на цифровата сигнатура за сравнение падна от около 18 сек на под 1 сек като минах на асемблер. Ако и с аес-а има подобно подобрение ще е супер .