Технология динамической загрузки модулей для RTOS, Какие есть методы и инструменты. Опции

[AlexandrY]

Как-то тут проскочила мысль, что настоящая операционная система должна грузить сторонние приложения и выполнять их.

Очевидно, что это реализовать для небольших проектов и даже не с ОС совершенно элементарно.
Для этого при компиляции основного ядра делают symbol definition file и потом этот файл и файлы хидеров передают третьей стороне чтобы те могли правильно скомпилировать и слинковать свои приложения для ядра.

Но когда в ядре количество функций переваливает за тысячу, то сделать переносимые хидеры в ручную представляется проблемой.
Также желательно сделать отдельный модуль с так называемой jump table чтобы уменьшить зависимость от мелких изменений и перекомпиляций ядра. Как-то подумать о фильтрации, чтобы не все подряд сущности из ядра попадали в symbol definition file и т.д.

И тогда вопрос - заморачивается ли кто-нибудь с этим и известны ли инструменты автоматизации всего этого процесса.

[a9d]

Для начала

Операционная система (Operating system) по ГОСТ 15971-90
Совокупность системных программ, предназначенная для обеспечения определенного уровня эффективности системы обработки информации за счет автоматизированного управления ее работой и предоставляемого пользователю определенного набора услуг [из п. 16 Таблицы 1 ГОСТ 15971-90]

операційна система - сукупність програмних засобів,
призначених для автоматизованого керування виконанням програми та
надання користувачам певних послуг (ДСТУ 2938-94, п. 4.16);

Как видно загружать программы не обязательно.

Можно использовать Си подобные скрипты. Тогда не будет зависимости от версии ядра. Но размер скриптов будет большим и пострадает производительность.

Сообщение отредактировал a9d - Dec 29 2012, 22:04

[haker_fox]

И тогда вопрос - заморачивается ли кто-нибудь с этим и известны ли инструменты автоматизации всего этого процесса.

Очень интересный вопрос! Я тут как-то даже чуть для scmRTOS под ARM это не попытался сделать загрузку модулей и программ "как в дос или виндовс". Конечно, в масштабах домашней мастерской. Но не хватило квалификации)

[AlexandrY]

Как видно загружать программы не обязательно.

Можно использовать Си подобные скрипты. Тогда не будет зависимости от версии ядра. Но размер скриптов будет большим и пострадает производительность.

ГОСТ конечно сильный аргумент, но те кто задает моду на OS-и про ГОСТ наверно мало знают, если вообще знают.

Скорее имеет смысл говорить от том, как оптимальней разделить функциональность и организовать взаимосвязь между осью и приложением в смысле технологичности, удобства, простоты и пр.
Тут интересны мнения бывалых.

Скажем та же функция загрузки сторонних приложений написанных на C-и в ось без виртуализации памяти выглядит очень опасной.
Скорее это подход из прошлого века времен DOS.
Т.е. для малых RTOS такая фича дала бы не преимущество, а большую проблему. Значит загрузку программ на С-и вычеркиваем из списка must-have.

Если говорить о HAL в RTOS. (это вдогонку закрытой предыдущей темы)
Тут тоже не все так просто. Обычно разработчики очень неохотно меняют семейства микроконтроллеров. Это довольно трудное занятие.
Именно потому, что вынуждены детально изучать всю аппаратную часть платформы.
Тогда зачем абстракции? Что HAL уровень упрощает в RTOS кроме переносимости верхнего уровня?
Но рискну предположить, что именно переносимость меньше всего волнует разработчиков. Она скорее важна тем кто разрабатывает оси чтобы расширить сегмент сбыта. Т.е. HAL ставим под вопросом в списке must-have для RTOS, хотя вообще для осей фича стоящая.

[a9d]

Насколько я помню в винде адреса API функций программа получает по ANSI именам. Так решиться проблема с адресацией.

Тогда нужно реализовать функцию которой передается имя функции а она вернет адрес. Этот адрес загоняем в массив и дальше используем.
Но эта не самая большая проблема. MMU все таки нет а значит будет тоже самое, что и с uclinux.

Сообщение отредактировал a9d - Dec 30 2012, 22:36

[haker_fox]

Гм... чувствую благовейный ветерок) Как когда-то для восьмибитников RTOS была желанной новинкой. Так сейчас и в RTOS будут появляться возможности запустить скомпилированную "дядей Васей" левую программу, модуль или драйвер. Вообще для ARM7TDI хотябы уже актуальная задача. Не могу реализовать. Но очень бы хотелось, не перепрошиваю всю программу целиком, завершать исполнение одной, а загружать новую) Я в теме? Или речь о другом?)

[AlexandrY]

Насколько я помню в винде адреса API функций программа получает по ANSI именам. Так решиться проблема с адресацией.

Тогда нужно реализовать функцию которой передается имя функции а она вернет адрес. Этот адрес загоняем в массив и дальше используем.
Но эта не самая большая проблема. MMU все таки нет а значит будет тоже самое, что и с uclinux.

Это вы наверно имеете в виду как выполняется динамическое связывание для dll.
Это известный стандартный способ, но для этого ядро должно содержать в себе таблицу символов.
В моих проектах с RTOS такая таблица заняла бы более 300 Кб в RAM.
Даже жирным однокристалкам с Cortex это будет уже за много.
Это не считая того, что сами загруженные таким образом модули подвергаются модификации, т.е. должны выполняться из RAM или по крайней мере по началу туда грузиться.
Решение, скажем прямо, не совсем для малых RTOS.

[a9d]

А как планируете решать проблему с MMU ? Также как и в uclinux?

[AlexandrY]

А как планируете решать проблему с MMU ? Также как и в uclinux?

В тех однокристаллках которые я подразумеваю нет MMU, соответственно нет и проблемы

Но интересно какую проблему MMU вы имеете ввиду?

[a9d]

Вот об отсутствии и идет речь.

Вот простой пример.
В программе A по смещению 0 располагается переменная int.
В программе B по смещению 0 располагается переменная char.
Как планируете решать эту ситуацию?

В uclinux каждая программа знает какое адресное пространство занимает. Это создает неудобства.

[AlexandrY]

Вот об отсутствии и идет речь.

Вот простой пример.
В программе A по смещению 0 располагается переменная int.
В программе B по смещению 0 располагается переменная char.
Как планируете решать эту ситуацию?

В uclinux каждая программа знает какое адресное пространство занимает. Это создает неудобства.

Какие же неудобства от того что известно расположение программы?
По моему наоборот облегчается отладка.

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

Существуют несложные механизмы и по размещению программы с произвольного адреса в пределах разрешенных зон. Это например elf-загрузчики. Они грузят не бинарник, а объектный файл с формате elf. При загрузке они превращают файл в бинарник с подменой адресной информации в операторах на реальные адреса.

[haker_fox]

Существуют несложные механизмы и по размещению программы с произвольного адреса в пределах разрешенных зон.

Товарищи, а можно послать меня по нужным ссылкам? Я несколько нашел, но может быть Вы предложете более интересные материалы. AlexandrY, для меня Вы специалист очень высокого уровня, и хотелось бы получить пинок именно от Вас

[vshemm]

Как-то тут проскочила мысль, что настоящая операционная система должна грузить сторонние приложения и выполнять их.

Мысль не очень, динамическая загрузка приложений ортогональна понятию ОС.
Практика показывает, чем более эмдеддед ОС, тем проще и технологичнее использовать статическое связываение,
в виде либ + хидеров, например.

Про загрузку dll - там связывание может происходить по ординалам, т.е. тупо по номерам. Есть еще связывание по хешу,
тот же CRC32 подойдет, причем все делается на этапе компиляции (включая проверку на коллизии). Где смотреть
примеры реализации - тот же линух и сорцы прочих ос. Так что 300КБ можно уменьшить в разы. Грубо говоря, при экспорте
символа он оборачивается в макрос, строится отдельная секция, которую потом обрабатывает линкер в ld-скрипте.
Ну а загрузчик уже юзает данную секцию в своих целях.

Про загрузку кода по произвольным адресам - гуглите relocation и fixup. Классическая дока по эльфам (собственно,
виндовый PE формат это упрощенный эльф) - http://www.becbapatla.ac.in/cse/naveenv/docs/LL1.pdf
Там есть все - разные архитектуры, разный эндианнес, вопросы MMU...

[AlexandrY]

Про загрузку кода по произвольным адресам - гуглите relocation и fixup. Классическая дока по эльфам (собственно,
виндовый PE формат это упрощенный эльф) - http://www.becbapatla.ac.in/cse/naveenv/docs/LL1.pdf
Там есть все - разные архитектуры, разный эндианнес, вопросы MMU...

Книжка в целом очень хорошая, но как всегда что касается embedded не очень целевая.

Насчет loader-ов есть сильное семантическое отличие этого понятия в контексте компьютерной информатики и малых встраиваемых систем.
В компьютерах под loader-ами подразумевают просто размещение объектных файлов по физическим адресам.
Сопровождающие этот процесс действия и механизмы как бы очевидны и не являются ограничителями: операционка, файловые системы, выделение памяти, живые юзеры и т.д....
В малых же встраиваемых системах под loader-ами понимают все вместе: механизмы физической передачи, размещения и сохранения данных с кодом программы, связывание и размещение кода, запуск кода, менеджмент кода и т.д. Все и проще и сложнее. И на этот счет книжек нет. Все изобретают велосипеды.

Пока единственный виденный мной доступный, рабочий, переносимый, чисто написанный elf-loader а видел в исходниках VwWorks. Они есть в местном хранилище.
Про статическое связывание лучше чем в доке на сами средства компиляции не найти. Поэтому прямиком на сайт www.arm.com - "Application Note 242"

[vshemm]

Насчет loader-ов есть сильное семантическое отличие этого понятия в контексте компьютерной информатики и малых встраиваемых систем.

Боюсь, что семантические отличия исключительно ваши. Мы вообще обсуждаем динамическую загрузку
модулей (см. топик). В данном контексте лоадер - это код, который готовит некоторые данные для
работы (данные - это как код и как собственно data). Лоадер пользуется внешним апи, типа чтения
данных, выделения памяти и т.д. Реализация этого апи находится вне текущей абстракции, а "файловые
системы", "живые юзеры" вообще тут никаким боком.

Дока по L&L на примере ELF-а описывает как раз компоновку софта и последуещее развертывание
на девайсе. Есть и другие форматы, но ELF настолько получился удачным и гибким, что решает в 95%.
В любом случае, человек, хотя бы ознакомившийся с этой докой сможет сформулировать запрос в гугл

Разница между "компьютерными системами" и "малыми встраиваемыми системами" заключается только в
ресурсах. Т.е. надо дать определение, что такое малые встраиваемые. Моя эмпирическая оценка -
это 64КБ RAM, если меньше, то нужны *очень* веские доводы для реализации динамической загрузки.
Но никто даже в противном случае не мешает создать прошивку в виде эльфа, где уже бутлоадер
(даже являющийся частью того самого эльфа) будет загружать всю систему (ОС + прикладнуха).
Вообще, gcc + binutils + make + objcopy позволяет делать любые вещи, начиная от генерации под
виндой опшнромов, досовских EXE- и COM-файлов и заканчивая велосипедами для контроллеров. Но это
так, лирика.

Пока единственный виденный мной доступный, рабочий, переносимый, чисто написанный elf-loader а видел в исходниках VwWorks. Они есть в местном хранилище.
Про статическое связывание лучше чем в доке на сами средства компиляции не найти. Поэтому прямиком на сайт www.arm.com - "Application Note 242"

elf-loader есть как минимум в линуксе (тоже чистый и кросс), в BSD-like, QNX и т.д. Но они несколько
громоздки для начального изучения, поэтому я позволю себе дать пару ссылок: prex и embox. Первый
тоже кросс и MMU-независим, второй более наворочен, но требует MMU.

[desh]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

[AlexandrY]

Боюсь, что семантические отличия исключительно ваши. Мы вообще обсуждаем динамическую загрузку
модулей (см. топик). В данном контексте лоадер - это код, который готовит некоторые данные для
работы (данные - это как код и как собственно data). Лоадер пользуется внешним апи, типа чтения
данных, выделения памяти и т.д. Реализация этого апи находится вне текущей абстракции, а "файловые
системы", "живые юзеры" вообще тут никаким боком.

Это вы описали компьютерный взгляд на лоадер.
Если во встраиваемой системе нет даже элементарной файловой системы, вы не можете так просто отмахнуться от API вне"текущей абстракции"
Это качественное отличие.
Я в начале заострил внимание на задачах интеграции лоадера в готовые проекты,
а сами реализации непосредственно конвертеров elf в bin особого внимания не требуют поскольку есть известные исходники.

[neiver]

Насчёт взаимодействия загружаемого модуля и ядра, моногие ARM-ы, например, имеют команду SVC - Supervisor Call, которая вызывает соответствующий обработчик прерывания, которому передаётся аргумент команды - номер системного вызова. Параметры ему можно мередавать через регистры. И никаких JUMP-таблиц или таблиц символов.

[_Pasha]

SVC - Supervisor Call, которая вызывает соответствующий обработчик прерывания, которому передаётся аргумент команды - номер системного вызова. Параметры ему можно мередавать через регистры. И никаких JUMP-таблиц или таблиц символов.

Кроме того, что JMP-таблица будет в теле обработчика SVC
Проблема-то в невозможности на всех архитектурах создать модель с относительными переходами и вызовами.

Сообщение отредактировал _Pasha - Jan 16 2013, 15:10

[SyncLair]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

для AVR он немного "испортил" эльф и сделал его 16-и битным

Насчёт взаимодействия загружаемого модуля и ядра, моногие ARM-ы, например, имеют команду SVC - Supervisor Call, которая вызывает соответствующий .....

Вот этот пример показывает разницу между ABI и API ибо в первом случае чётко определены параметры вызовов и поэтому любая "прикладная задача" в ОС может воспользоваться функциями. Вопрос только в с ледующем а как же быть если есть задача и библиотека, и сначала грузиться библиотека а потом задача? и функции библиотеки не определены в SVC.


И на последок:

Координальное на мой взгляд решение в ембеддед мире -- специально готовить исполняемый прикладной файл с учётом того, что уже есть на плате. То есть линкер должен знать какое состояние флеши в контроллере и готовить очередной "прикладной процесс" (понятно что прикладной в смысле не ОС которая УЖЕ в МК) с учётом того что уже есть на плате. То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Или если совсем просто, то пусть линкер линкует старые и новые объектные файлы только старые размещает по старому с нулевого адреса а новые далее. В этом случае загрузчику остаётся только сначала сделать memcmp, а уж потом оставшийся новый код догрузить во FLASH.

[haker_fox]

То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Это правильно, но как этого добиться от линкера? Он-то о существовании оси не знает.
Допустим, у нас есть API для уже загруженной в МК операционки:

CODE

namespace OSAPI
{
void sleep( msec );
...
...
...
TPrio getSelfPrio();
...
...
...
void sendchar( char a );
}

Совершенно разные функции, которые уже есть в оси, на которые уже все заточено (прерывания, периферия, ядро). Допустим, мы решили воспользоваться одной из функций в нашем прикладном коде (драйвер, подгружаемая библиотека, просто программа):

CODE

....
int main( void )
{
....
while( 1 )
  {
    OSAPI::sleep( 100 );
    OSAPI::sendchar( '!' );
  }
....

Вот как объяснить линкеру, что нужно подставить только адреса функций, передать и принять аргументы.
Кроме, как в заголовочнике задать адреса этих функций (точно также, как мы делаем это в одном проекте "по месту") у меня идей нет... Вопрос, как сделать это красиво?

[AlexandrY]

Это правильно, но как этого добиться от линкера? Он-то о существовании оси не знает.

Вот как объяснить линкеру, что нужно подставить только адреса функций, передать и принять аргументы.

Кроме, как в заголовочнике задать адреса этих функций (точно также, как мы делаем это в одном проекте "по месту") у меня идей нет... Вопрос, как сделать это красиво?

Как это линкер не знает?

Первое.
Вы в проект вставляете файлы с объявлениями функций и процедур оси которые собираетесь использовать. Собираете, разруливаете зависимости, пишите если надо и концентрируете их в одном месте естественно руками.

Второе.
Вы подключаете к проекту symbol definition file который получаете автоматически когда компилируете ось перед загрузкой на голую платформу (не забыв галочку соответствующую поставить, естественно).

Этой информации линкеру более чем достаточно.

[kolobok0]

..есть API для уже загруженной в МК операционки...мы решили воспользоваться одной из функций в нашем прикладном коде...нужно подставить только адреса функций, передать и принять аргументы..

под AVR делал так:
имеем таблицу джампов переходов. Адресс таблицы "зашит жёстко". Сам по себе вектор может указыватьна любой адресс. А чтоб вызвать из прикладной прожки - то адресс известен. получается, что из любого места позвали известный адресс джамп перехода из ядра.

под stm32 сейчас делаю более навороченную модель - там собственно уже всё динамически вяжется. и собственно в загрузчике почти ничего уже и нет

[haker_fox]

Вы подключаете к проекту symbol definition file который получаете автоматически когда компилируете ось перед загрузкой на голую платформу (не забыв галочку соответствующую поставить, естественно).

Ага! Про symdef слышу впервые. Зато теперь все вяжется! Спасибо

под AVR делал так:
имеем таблицу джампов переходов. Адресс таблицы "зашит жёстко". Сам по себе вектор может указыватьна любой адресс. А чтоб вызвать из прикладной прожки - то адресс известен. получается, что из любого места позвали известный адресс джамп перехода из ядра.

Кажется, это все вручную... печально

[AlexandrY]

под stm32 сейчас делаю более навороченную модель - там собственно уже всё динамически вяжется. и собственно в загрузчике почти ничего уже и нет

А вот интересно , какой смысл у такой организации софта.

Вижу три варианта: для себя, для коллег в своей организации, для сторонних разработчиков.

Чтобы делать это для себя тут я вижу оправдание только в некоей эстетике, не относящейся к объективной необходимости.
Чтобы делать для коллег, то наверно это вызвано технологическими особенностями процесса разработки, а не потребностью приложения как такового.
Для сторонних разработчиков такой подход вызовет потребность создания огромного объема документации, проблемы с тех поддержкой. Для самих сторонних разработчиков вызовет проблемы с отладкой.

А где положительные стороны такого подхода? Я не могу увидеть.

[kolobok0]

..какой смысл у такой организации софта....

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

[AlexandrY]

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

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

В малых встраиваемых системах время загрузки вообще ничтожно. Килобайт или мегабайт вы грузите никто не заметит. Разница будет в долях секунды. Некоторая периферия гораздо дольше инициализируется.

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

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

Т.е. я как бы совсем не понял ваших аргументов.

[haker_fox]

Т.е. я как бы совсем не понял ваших аргументов.

Мне кажется, что динамическая загрузка (запуск) модулей (совсем как в "настоящих" осях) упрощает отлдаку приложения. Вместо того, чтобы постоянно перезагружать всю прошивку, даже если она в RAM, проще выгрузить и загрузить новую версию модуля. Хотя да, аргументация, конечно слабовата с моей стороны. Больше сил уйдет на написание загрузчика, планировщика, что там еще... менеджера памяти.

Гм, мне кажется это имеет место быть на платформах с MMU. А то толку отлаживаться - модуль обратится к чужой памяти, а процессор и не чухнет, даст перезаписать ядро оси, и ку-ку Но для MMU уже есть Linux, Win CE...

Что же получается, бессмысленно это, что ли?


Хотя нет. У меня есть один проектик, который работает круглые сутки, и управляет неким процессом. Сбои там, конечно, не нужны, но небольшие простои - не страшно. Так вот, чтобы постоянно не останавливать систему, некоторые модули, включающие определенные алгоритмы от друг друга не зависящие, можно и перезагружать в рантайме. Даже если и будет нарушение адресного пространства, то не страшно. Зато шанс обновиться "наживую".

[kolobok0]

...мало относящемся к загрузке сторонних приложений.

именно так. для сторонних приложений нужно озабачиваться бОльшей секьюрностью, которую по идее надо поддерживать на уровне железа. либо "условно сторонних"

...или мегабайт вы грузите никто не заметит. Разница будет в долях секунды...

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

...Апдейт софта проще сделать...

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

..Иначе головная боль с совместимостью версий софта...

для меня - это пройденный этап. с точки зрения исполнения - пара-тройка экранов на сях...

...я как бы совсем не понял ваших аргументов.

и вас вылечим
я собственно не спорю. скорее всего я не прав. человек спрашивал я ответил... тащить кого то в колхоз - честно слово времени нет вообще...

[SyncLair]

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

Если вы предоставляете систему сборки и бинарый файл ОСи то ничего он не создаёт!

Хотя нет. У меня есть один проектик, который работает круглые сутки, и управляет неким процессом.

У меня тоже есть пример когда. "Обновление ПО контроллера без остановки контроллера." В этом случае мне бы как раз помогло обновлять только то что хочу. Ну например: загрузил вверсию 2 а работает версия 1, далее перезапустил процесс на новую версию.

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

Поддерживаю аргумент -- вот Дункельс и пляшет с обновлением по всяким там Mesh сетям.

[AlexandrY]

Если вы предоставляете систему сборки и бинарый файл ОСи то ничего он не создаёт!


У меня тоже есть пример когда. "Обновление ПО контроллера без остановки контроллера." В этом случае мне бы как раз помогло обновлять только то что хочу. Ну например: загрузил вверсию 2 а работает версия 1, далее перезапустил процесс на новую версию.



Поддерживаю аргумент -- вот Дункельс и пляшет с обновлением по всяким там Mesh сетям.

Что такое "система сборки" и как она заменяет документацию?

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

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

[SyncLair]

Что такое "система сборки" и как она заменяет документацию?

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

Система сборки -- на входе ваши бинарники + исходники клента -- на выходе исполняемый файл -- ну makefile например и куча куча всяких служебных скриптов и файлов или плагин к Eclipse-у.

Никак не заменяет, просто уменшает ОГРОМНЫЙ размер документации если клиенту иногда надо
пином подёргать и вывести на екран что-нибудь, в то время как ваши внутренние модули могут быть впринципе не продокументированы хорошо.

В случае проблем со сборкой и даже наоборот требует на себя ЕЩЁ документацию в самом плохом случае но если вы просто дали вашему клиенту инструмент по сборке -- он же студия разработки, то у вас до поры до времени нет проблем (а рано или поздно клиенту что-то экзотическое потребуется по закону мерфи).
Ну и конечно ваша базовая часть, естественно, должна быть продокументирована НО только интерфейсы, а внутренности вшей базовой части конечно можно не документировать.


часть 1 -- ОС(с загрузчиком) + часть2 -- управление каким-нибудь технологическим процессом

часть1 -- с 0 по ххх адрес
часть2.0 --- с ххх адреса по ууууу адрес
часть2.1 --- с уууу адреса по зззззз адрес

изменяя адрес начальной загрузки 2 части создаём образ части№2 и по меееееедленому каналу загружаем часть2 во флеш ПАРАЛЕЛЬНО с работающей системой Далее TaskDelete(2.0) + TaskCreate(2.1)