Добрый день!
Хочется сделать rootfs только для чтения и небольшой кусочек с конфигами rw. Физически я это представляю так: Linux и rootfs в NAND и они read only. Далее инит скрипт цепляет фс c EEPROM, с текстовыми конфигами и вытягивает в ОЗУ и монтирует в /tmp (NAND EEPROM и /tmp взяты для примера).
Кто нибудь делал подобное? Как мне ограничить область озу где будут сидеть эти конфиги от перезаписи? Как в инит скрипте их инициализировать? Какие могут возникнуть проблемы ведь дальше программы надо будет запускать с этими конфигами? Как их записывать и понять что они записались?
Чтобы два раза не вставать еще вопросик. Как обычно делают обновление в подобных встроенных системах (я себе представляю это обновлением части rootfs)

Воспользуйтесь tmpfs:
mount -t tmpfs tmpfs /tmp/ram
Как инициализировать - смонтируйте куда-нибудь fs из eeprom, скопируйте содержимое в /tmp/ram, размонтируйте eeprom.
Ограничивать Вам ничего не надо, это забота ядра.


Понятия не имею. Программа будет работать с файлами на файловой системе. Тот факт, что файловая система физически расположена в ОЗУ, ее, по идее, волновать не должен...


Не понял... Как записывать кого? Файлы? Открыть файл вызовом open(), записать вызовом write(), закрыть вызовом close(). Успешность каждой из этих операций контролируется по возвращаемым или значениям.


Есть (как минимум) два подхода (лично я использую оба - в одних изделиях один, в других - другой):

1. Использование пакетов и пакетного менеджера - то есть точно так же как в обычных десктопных системах: есть репозиторий пакетов на сайте в интернете, пакетный менеджер оттуда скачивает и устанавливает обновления. Удобно когда разные экземпляры устройства могут иметь разный набор установленных пакетов, когда общий объем софта достаточно большой, и когда требуется минимизировать (или исключить) время простоя системы в процессе обновления. Раз Вы говорите об обновлении части rootfs, то это - ваш метод. На время обновления rootfs придется, естественно, перемонтировать в режиме rw.

2. Обновление целиком - загрузчик (например u-boot) загружает откуда-то и записывает в ПЗУ готовый образ. Удобно когда общий объем данных небольшой, и когда устройство не содержит уникальных данных. Недостатки - любое даже незначительное обновление требует загрузки всего образа, для любого обновления требуется перезагрузка системы, следовательно, перерыв в работе устройства.

Спасибо исчерпывающе. Почитал про tmpfs все отлично но есть проблемка обратной записи в EEPROM. При этом получается что после записи каких-то данных в tmpfs(которая у нас типа копия EEPROM) мы должны подмонтировать устройство обратно и записать то что у нас находиться в tmpfs в EEPROM и отмонтировать его (а если я там лог собираю? не нужный потом для записи).

Про пакеты и пакетный менеджер. Получается я должен собрать для своего SoC этот пакетный менеджер, скопировать туда разместить в устройстве небольшую БД установленных пакетов. Мне кажется это "не наш метод". (к слову у меня imx287) Обновление я так предполагаю будет через ВЕБ интерфейс (наподобие роутеров всяких WiFi ных). Неужели для этого все же нужен отдельный загрузчик? Uboot поддерживает WEB сервер на себе или ему передать можно переменные новой загрузки через файл какой-то? Где это можно почитать посмотреть? Я так полагаю на OpenWRT (к слову я пытался там про CGI почитать - ну очень мало)

а не проще ли просто выделить под настройки отдельный раздел на mtd устройстве и смонтировать его как хочется (/etc в rw)?

Может и проще будет действительно. Мне тут нужна консультация. Физически mtd у меня NAND. На данный момент она видится в системе как пара символьных и пара блочных устройств. Т.е. мне ее надо разбить.отформатировать на следующие разделы:
kernel image RO
rootfs RO
/tmp RW
Т.е. бутлет инициализирует питание, ОЗУ, NAND и дает команду вычитывать первый раздел с NAND оттуда грузиться ядро(ну или uboot) с драйвером ФС и командной строкой в которой прописано что rootfs читать с такого-то раздела NAND, монтирует rootfs, используя драйвер jffs уже ядра, запускает init и далее уже где-то в скриптах монтирует в систему /tmp. Т.е. NAND уже должен быть отформатирован чтобы я мог прописать название партиций.

С другой стороны не хочется NAND дергать постоянно на запись. Проще по SPI подключить EEPROM и монтировать ее куда надо.

Судя по этим предложениям топикстартер не сильно знаком с Linux, может поэтому и много вопросов?

С spi eeprom видимо будет удобнее вообще через sysfs работать, т.к. объем небольшой



На веб-сервер в линуксе грузится архив обновления методом post, скрипт на стороне сервера проверяет целостность архива и распаковывает его, ну а дальше - в зависимости от содержимого архива: либо меняются отдельные файлы, либо перезаписываются образы разделов, либо подкачивается обновление из репозиториев.
В случае перезаписи разделов нужно больше памяти,ну и корень нужен другой в ram
В случае обновления из репозиториев видимо придется как-то изголяться в offline.
Думаю, обновление через веб через загрузчик - это как-то сложно. Обновление через загрузчик удобнее для обновления с каких-то внешних носителей. Типа нажали три кнопки - загрузчик пошел по другой ветке, нашел образы на sd карте, все перепрошил и загрузил.

Почему же? Что именно Вас смущает?
Обновление через менеджер пакетов работает примерно так:
1. Менеджер скачивает с некоего сервера (http/ftp) свежий список пакетов.
2. Сравнивает версии установленных пакетов с имеющимися в списке.
(как альтернативный вариант, вместо пунктов 1 и 2 можно вручную передать на устройство файл пакета, о чем написали выше)
3. Если в списке обнаружены пакеты новее, чем установленные в данный момент, эти пакеты скачиваются, распаковываются и устанавливаются на место старых. Причем установка - это не просто копирование новых файлов на место старых. Пакет может, например, содержать скрипты, выполняющиеся при установке/удалении/обновлении...


При использовании пакетного менеджера как раз никакая перезагрузка не требуется. Система обновляет себя сама без участия u-boot или какого-либо еще загрузчика.
У меня устройства прекрасно обновляются нажатием в веб-интерфейсе кнопки "Проверить обновления", и затем (если показывает, что обновления есть) "Выполнить обновление"...

А u-boot, конечно же, никакого web-сервера не имеет...

Сообщение отредактировал alx2 - Jun 3 2015, 12:28

Небольшой пример по boot есть на http://www.zao-zeo.ru/dokuwiki/doku.php/u-boot

Вообще Вы не описали конфигурацию своей системы, может в Вашем конкретном случае можно грузить через uboot только ядро,
а fs держать например на NFS:
1) http://www.stlinux.com/u-boot/kernel-booting
2) http://www.denx.de/wiki/view/DULG/LinuxNfsRoot

тогда отпадает необходимость апдейта firmware как таковой, но опять же всё зависит от конфигурации вашего случая!

Вы сильно не пинайте просто мне приходиться в данный момент быть "и швец и жнец и на дуде игрец". По большой части со всеми этими кусочками я работал на серверных системах. С embedded немного другая жизнь постоянно приходится к аппаратной части привязываться и к BSP. Я пока собираю под задачи ПО и адаптирую код немного под железку. Следующий этап будет написание CGI прослойки для конфигурирования железяки через WEB (пока начну с примитивных текстовых или строковых конфигов). Ну и последний этап - возможность обновления ПО. По CGI и обновлениям я в режиме накопления информации.
C rpm(а именно он идет в составе моей BSP) я попробую поиграться и насколько я представляю пакетные менеджеры они могут работать как с репозиторием так и с отдельными оффлайн пакетами. В этом случае онлайн репозиторий надо городить либо оборачивать пакеты или группы пакетов скачивать их на устройство и потом разбирать.(вот это более реально в смысле оффлайн)
Про режимы загрузки: NFS конечно очень удобно но боюсь в моем случае в реальном применении этого не будет (максимум ФТП какой нибудь с конфигами xml ными)

nand флешки хорошо дружат с yaffs2. поэтому вы вполне можете иметь три раздела на флешке.

BSP шное ядро yaffs2 не поддерживает. Для NAND UBIFS и JFFS2 поддерживается

А что мешает сделать две партишн и одну монтировать как read only, а вторую как read/write?

У меня такой вопрос возник. Ядро на первом этапе само монтирует для себя файловую систему в соответствии с аргументами командной строки. Смая внятная статья на эту тему Статья Т.е. ядро формирует для себя небольшую файловую систему там всего несколько папок создается по умолчанию потом оно в /dev прицепляет то что в командной строке обозначает хардварный диск и потом там ищет и запускает уже init. В моем случае это инит busybox-а и дальше начинается канитель с инициализирующими скриптами. Фактически та часть памяти которую ядро заняло для процесса поиска и запуска init не нужна и может быть освобождена. В какой момент размонтируется то что ядро для себя создало и какими механизмами? Зачем в принципе в командной строке ядра есть опции ro и rw если потом в инициализирующих скриптах можно все перевернуть?