Comments 65
Вопрос как професиионалу.
Что для дома и семьи посоветуете на текущий момент — orange pi, banana pi
raspberry pi или алиэкспресс?
Что для дома и семьи посоветуете на текущий момент — orange pi, banana pi
raspberry pi или алиэкспресс?
Что выбрать, это дело вкуса. Если вы новичок, то советую raspberry. Если профи, то берите смело любой одноплатник под ваши нужды. Лично я на orangepi zero и lichee pi собирал и использовал yocto, все как по маслу собирается и заводится.
Про NanoPI NEO Core2 нет ли мнения?
И сразу… не дtлаете ли Вы UPS на маленьком аккумуляторе или ионисторе, передавая на GPIO сигнал о потере питания?
И сразу… не дtлаете ли Вы UPS на маленьком аккумуляторе или ионисторе, передавая на GPIO сигнал о потере питания?
Nano pi не тестировал, по характеристикам приличное железо.
Но нет меганадежного накопителя для загрузчика. Загрузчик придется размещать в emmc с основной сборкой, плюс двусторонний монтаж, поэтому на плату пузом не посадишь, только через разъем.
По поводу UPS, то эта задача для stm32. Лично я этим не занимаюсь, но могу спросить у коллег, сформулируйте задачу в личку, я передам.
Но нет меганадежного накопителя для загрузчика. Загрузчик придется размещать в emmc с основной сборкой, плюс двусторонний монтаж, поэтому на плату пузом не посадишь, только через разъем.
По поводу UPS, то эта задача для stm32. Лично я этим не занимаюсь, но могу спросить у коллег, сформулируйте задачу в личку, я передам.
вот это не подойдёт? www.crowdsupply.com/silicognition/lifepo4wered-pi-plus
готовое, для малины. на одно устройство не так дорого.
готовое, для малины. на одно устройство не так дорого.
Это по разным причинам может и подойти. Но продаётся ли оно, не очень ли оно дорогое, может ли использоваться не с RPi — вопросов много. Автор порассуждал о конкурентах, и там много интересного всплывает, так что устройство заслуживает внимания. Но это самоделка, как она будет поставляться неизвестно (скорее всего никак).
(Так-то можно было бы собрать из двух компонентов — контроллера аккумулятора и повышающего преобразователя, просто собрать проводочками и приклеить к батарейному отсеку, но не будет рапорта о проблемах и будут разные нетривиальные случаи).
(Так-то можно было бы собрать из двух компонентов — контроллера аккумулятора и повышающего преобразователя, просто собрать проводочками и приклеить к батарейному отсеку, но не будет рапорта о проблемах и будут разные нетривиальные случаи).
RaspberryPi — 2 штуки. Использовать рекомендации автора статьи по поводу Readonly и Ramdisk для сохранности SD карты(полно статей в инете), питание через Powerbank(только следить, чтобы напряжение давал повыше). Так будет работать долго — у меня 4 года трудился.
Второй Распбери с SD картой прошить образом первого и положить рядом. На всякий случай.
У китайских клонов малины есть определённые трудности, то нет нужной версии ОС, или версия есть, но именно в ней нет поддержки чего-то, что было в прошлой версии, то конкретная версия ПО не работает в конкретной версии ОС.
С малиной немного лучше в этом плане, большее сообщество исправило больше багов.
С малиной немного лучше в этом плане, большее сообщество исправило больше багов.
Про ODROID почему-то все забыли. А Ведь он тоже весьма хорош)
Smart TV Box на AmLogic ;)
Какие у вас требования к аппаратной начинке одноплатников? Почему не использовали OpenWrt?
Требования к начинке зависят от задачи.
Мин требования 64Мб DDR2, 256Мб ROM (любого типа), CPU 500MHz.
Изначально у меня была задача, которая требовала нечто готовое. Я поглядывал в сторону openwrt, понял что это проект для создания роутеров и не более, шаг в сторону, начинаются квесты и приключения.
Поэтому решил, что проще разработать свой проект, чем тащить пласт неизвестного для меня кода, с неизвестными ошибками и подводными камнями. Все хорошо на словах, его рекламируют, у него большое сообщество, много отличных роутеров на его базе создано, но вот например сколько нужно потратить времени, что бы из него сделать видеодомофон, сколько нужно времени что бы весь его WEB интерфейс переделать под свои задачи да так что бы ничего не ломалось, хороший вопрос.
Плюс как можно гарантировать стабильность решения не зная его на 100%. Поэтому было принято решение, разработать свой проект в котором перечисленные вопросы отпадут сами собой.
Мин требования 64Мб DDR2, 256Мб ROM (любого типа), CPU 500MHz.
Изначально у меня была задача, которая требовала нечто готовое. Я поглядывал в сторону openwrt, понял что это проект для создания роутеров и не более, шаг в сторону, начинаются квесты и приключения.
Поэтому решил, что проще разработать свой проект, чем тащить пласт неизвестного для меня кода, с неизвестными ошибками и подводными камнями. Все хорошо на словах, его рекламируют, у него большое сообщество, много отличных роутеров на его базе создано, но вот например сколько нужно потратить времени, что бы из него сделать видеодомофон, сколько нужно времени что бы весь его WEB интерфейс переделать под свои задачи да так что бы ничего не ломалось, хороший вопрос.
Плюс как можно гарантировать стабильность решения не зная его на 100%. Поэтому было принято решение, разработать свой проект в котором перечисленные вопросы отпадут сами собой.
.
Интересно, но плохо читается без примеров.
Напишите как реализовано всё вышеописанное в Raspberry Pi 3 (Pi 4) и Orange Pi.
Что-то не нашел в портфолио про 11-parts. Можно ссылку?
Было бы интересно почитать о:
— повторителе RS485 через 4G/WiFi/LAN,
— VPN шлюзе,
— системе контроля линий(кстати, о каких линиях речь?) и
— комплексной системаеуправления климатом ангара.
Напишите как реализовано всё вышеописанное в Raspberry Pi 3 (Pi 4) и Orange Pi.
Что-то не нашел в портфолио про 11-parts. Можно ссылку?
Было бы интересно почитать о:
— повторителе RS485 через 4G/WiFi/LAN,
— VPN шлюзе,
— системе контроля линий(кстати, о каких линиях речь?) и
— комплексной системаеуправления климатом ангара.
Конечно, 11-parts.com/ru/portfolio
Насколько я понял, в RPi 4 пришли к описанному Вами. Ну почти пришли…
Есть SPI чип на борту с бутлодером, обещают допилить настоящий USB boot, так чтобы SD карта вообще была бы не нужна. А на USB бери да и вешай нормальный SSD, который вместе с набортными конденсаторами и/или алгоритмом записи и гарантировано доживет до записи блока после его стирания (что и является проблемой окирпичивания SD) при срыве питания…
Есть SPI чип на борту с бутлодером, обещают допилить настоящий USB boot, так чтобы SD карта вообще была бы не нужна. А на USB бери да и вешай нормальный SSD, который вместе с набортными конденсаторами и/или алгоритмом записи и гарантировано доживет до записи блока после его стирания (что и является проблемой окирпичивания SD) при срыве питания…
Спасибо за статью. Кажется с eMMC всё было бы сильно проще: есть отдельные «аппаратные» бут-партиции, данные сами по себе не портятся, можно перестать всё хранить в raw и работать с файлами. Ну и нормальные eMMC не умирают сами по себе. Почему в новых продуктах продолжаете пользоваться NAND и SD-картами?
1. 256Мб NAND дешевле чем 4Gb emmc. Меньше 4G — emmc не производится. Если не
требуется большой объем, зачем переплачивать.
2. Архитектура NAND прозрачна.
Каждый производитель emmc использует свои алгоритмы, которые закрыты, это черный ящик хранящий сюрпризы в отличие от прозрачного NAND.
NAND имеет кучу минусов, которые можно обойти, в отличие от черного ящика emmc.
требуется большой объем, зачем переплачивать.
2. Архитектура NAND прозрачна.
Каждый производитель emmc использует свои алгоритмы, которые закрыты, это черный ящик хранящий сюрпризы в отличие от прозрачного NAND.
NAND имеет кучу минусов, которые можно обойти, в отличие от черного ящика emmc.
Полный бред.
1. Нет. Смотрите цены на бирже Шеньчженя.
2. Нет. Разброс параметров Nand как раз существенно влияет на качество выпущенного изделия, блочные устройства стабильнее в этом плане.
1. Нет. Смотрите цены на бирже Шеньчженя.
2. Нет. Разброс параметров Nand как раз существенно влияет на качество выпущенного изделия, блочные устройства стабильнее в этом плане.
1. Поскольку компания в которой я работаю, разрабатывает и производит электронику, мне известны цены официальных дистрибьюторов. Иногда в совместных проектах мне приходится самому заниматься поиском более дешевых замен. Дополнительно хочу отметить что чудес не бывает, emmc это NAND с контроллером, еще и большого размера, еще и с большими секторами типа MLC или TLC. Возможно вы нашли emmc дешевле, но это ничего не означает, может это остатки распродают, сегодня они есть, а завтра нет. Плюс еще влияет бренд, если сравнивать два разных бренда, например Micron и china noname, то результат может быть не предсказуемым. Дополнительно если уж сравнивать цены, нужно это делать в рамках одного бренда и NAND в сравнении нужно приводить с MLC или TLC плохого качества, а не дорогой SLC.
2. Ошибки NAND известны, к ним можно подготовится. С точки зрения блочного доступа, emmc лучше чем NAND, экономится программистское время, не нужно заморачиваться с UBIFS, e2fs и подобными узкоспециализированными ФС, не нужно заботится от карте битых секторов, не нужно устраивать танцы c несовместимостью ECC и т.д. Поэтому ее используют, про ее удобство я не спорю, и еще раз подчеркиваю, emmc удобнее NAND…
Я не готов в двух словах рассказать как работает emmc, нет времени, да и информации в гугле достаточно. Главное это то что emmc в фоне переносит сектора у которых сработал счетчик числа записей в другое менее зашкварное место. Физические сектора emmc размером например 1Мб, требуют время для переноса, плюс перед переносом требуется очистить сектор назначения. И вот представьте что будет если в этот момент вырубится питание. Я не говорю что emmc нельзя использовать, его весь мир использует. Просто хочу подчеркнуть небольшое преимущество NAND выраженное в простоте и открытости в отличие emmc, если проект имеет сборку размером 60Мб, то NAND это будет лучший выбор.
2. Ошибки NAND известны, к ним можно подготовится. С точки зрения блочного доступа, emmc лучше чем NAND, экономится программистское время, не нужно заморачиваться с UBIFS, e2fs и подобными узкоспециализированными ФС, не нужно заботится от карте битых секторов, не нужно устраивать танцы c несовместимостью ECC и т.д. Поэтому ее используют, про ее удобство я не спорю, и еще раз подчеркиваю, emmc удобнее NAND…
Я не готов в двух словах рассказать как работает emmc, нет времени, да и информации в гугле достаточно. Главное это то что emmc в фоне переносит сектора у которых сработал счетчик числа записей в другое менее зашкварное место. Физические сектора emmc размером например 1Мб, требуют время для переноса, плюс перед переносом требуется очистить сектор назначения. И вот представьте что будет если в этот момент вырубится питание. Я не говорю что emmc нельзя использовать, его весь мир использует. Просто хочу подчеркнуть небольшое преимущество NAND выраженное в простоте и открытости в отличие emmc, если проект имеет сборку размером 60Мб, то NAND это будет лучший выбор.
У меня вопрос слегка мимо темы, но вдруг сможете подсказать?
Я все пытаюсь понять, как бы поудобнее разработку под подобные системы вести. Пока что вижу такие варианты:
- Цепляться к одноплатнику по ssh или vnc (или просто клаву/монитор подключать), писать и компилить прямо там. Терпимо, но на одноплатнике приходится держать компилятор, IDE и т.д.
- Кросс-компиляция (поскольку одноплатники почти поголовно ARM'ы) и удаленная отладка. Писать комфортнее, компилировать может быть больно (поскольку приходится в своей системе держать либы, собранные под ARM); отладка может быть медленной и глючной. Если рабочий ПК под виндой — очень больно, приходится брать виртуалку с линуксом. Опять же, терпимо, рабочее окружение можно при желании затолкать в докер-образ.
Но хочется большего. Вот бы накатить на одноплатник просто голую систему, а свое приложение запускать из докерного контейнера! И тогда этот же контейнер можно бы и на рабочем компе запускать, с комфортом отлаживать, удобно версировать и т.д.
Но вот беда — докера под ARM нет :(
Хотя я вот сейчас погуглил для порядка и увидел, что три месяца назад он вроде как появился. Хм.
Тем не менее, может быть есть какие-то разумные альтернативы? Или я как-то вообще неправильно подхожу к этому процессу?
QEMU — виртуалка для армов.
Вы не могли бы раскрыть свою мысль чуть более подробно?
Ну например.
Вероятно, имелась в виду разработка в эмуляторе.
Интересно, насколько это медленно?
Зависит от того чего у вас за процы (как в девайсе так и в том кто будет эмулировать).
По моей инфе 5-летней давности: производительность qemu на 1 ядре Phenom II x6 @3.2GHz плюс-минус равна одному ядру OMAP2420 @400MHz. Только вот у фенома ядер шесть, а у OMAP'а всего одно. Ну и оперативы на десктопной машине может быть в разы больше. Поэтому смысл в эмуляторе очень даже есть.
С тех пор десктопные процы стали побыстрей. Да и наверняка qemu научилась эффективнее эмулировать.
По моей инфе 5-летней давности: производительность qemu на 1 ядре Phenom II x6 @3.2GHz плюс-минус равна одному ядру OMAP2420 @400MHz. Только вот у фенома ядер шесть, а у OMAP'а всего одно. Ну и оперативы на десктопной машине может быть в разы больше. Поэтому смысл в эмуляторе очень даже есть.
С тех пор десктопные процы стали побыстрей. Да и наверняка qemu научилась эффективнее эмулировать.
поскольку приходится в своей системе держать либы, собранные под ARM
Yocto Project максимально упрощает этот процесс. Он умеет отдельно собирать SDK для хостовой системы.
отладка может быть медленной и глючной
В эмбеддеде часто используют отладчики, работающие по USB 2.0 Full Speed (12MBit/s). Если у вас в железке есть езернет — о каких тормозах для отладки вы говорите?
о каких тормозах для отладки вы говорите?
Если честно, я говорю по своему (очень небольшому) опыту отладки из eclipse через ssh, подтормаживало заметно и соединялось через раз. Почему — понять я не смог, к сожалению.
Докер это отличное и модное решение, которое например ставит крест на костылянии
в ubuntu с окружением, он требует высокой квалификации, он не прост, в масштабах 10 лет это молодой проект, который набирает обороты.
Самый простой способ как мне кажется, это VirtualBox+eclipse+sublime+core i7+16Gb RAM
В наше время любой производитель чипов, делает поддержку в yocto.
С помощью yocto командой populate_sdk вы можете собрать SDK с компилятором, с правильными завистимостями, библиотеками, toolchain, binutils и т.д.
Например bitbake core-image-minimal -c populate_sdk
Далее переходите в папку своих исходников, запускаете скрипт из SDK, который правильно
натраивает окружение и пути к кросс библиотекам и компилятору. Затем собираете
без бубна, поскольку все нужные флаги устанавливает скрипт из SDK.
Полученное под ARM заливаете на девайс и вуяла.
Дополнительно советую использовать NFS, т.к. экономится много времени на разработку.
в ubuntu с окружением, он требует высокой квалификации, он не прост, в масштабах 10 лет это молодой проект, который набирает обороты.
Самый простой способ как мне кажется, это VirtualBox+eclipse+sublime+core i7+16Gb RAM
В наше время любой производитель чипов, делает поддержку в yocto.
С помощью yocto командой populate_sdk вы можете собрать SDK с компилятором, с правильными завистимостями, библиотеками, toolchain, binutils и т.д.
Например bitbake core-image-minimal -c populate_sdk
Далее переходите в папку своих исходников, запускаете скрипт из SDK, который правильно
натраивает окружение и пути к кросс библиотекам и компилятору. Затем собираете
без бубна, поскольку все нужные флаги устанавливает скрипт из SDK.
Полученное под ARM заливаете на девайс и вуяла.
Дополнительно советую использовать NFS, т.к. экономится много времени на разработку.
UFO just landed and posted this here
Билдить на девайсе — дикая дичь.
Настраиваете кросс хоть в виртуалке и делаете всё там.
Можно и тулы накатить на таргет, чтобы удаленно дебажить.
Ну и просто стартовать с нфс — это фактически из коробки будет в любом линуксе.
Но вот беда — докера под ARM нет :(Всегда был. Основное требование для его работы на каком-либо хосте — поддержка ряда опций в ядре хоста, нужных для контейнеризации. От архитектуры устройства это не сильно зависит, пусть там хоть PowerPC будет.
ubuntu не предназначена для readonly, и всегда что-то должна писать
Ubuntu конечно для одноплатников не очень годится, туда надо что-нибудь более минималистичное. Но вся запись на диск раньше отключалась одной настройкой, а с появлением systemd — двумя:
/etc/rsyslog.conf
*.* ~
/etc/systemd/journald.conf
[Journal]
Storage=noneФС aufs
aufs в ядро так и не приняли, сейчас советуют всем переходить на принятую в ядро overlayfs.
Статья интересная, спасибо.
Но вся запись на диск раньше отключалась одной настройкой
что-то вы явно поторопились с «вся».
куча процессов пишет что-то на диск, не только логи
И что же ещё пишет на диск в чистой системе, без каких-либо дополнительных сервисов?
Какой-нибудь systemd-timedated или ntp может сохранять offset, если нужны — можно нарезать им какой-нибудь tmpfs. Процесс login может обновить utmp и wtmp, но он переживёт невозможность в них писать.
Ещё snap может самостоятельно заниматься обновлением своих пакетов, но его в минималистичную систему ставить не надо.
UFO just landed and posted this here
Эх, если бы вы ещё так же хорошо написали как всё это делать…
Поддержка обновлений очень классная штука, у меня после данной статьи возникло желание
сделать следующее:
1) Всегда есть базовый (стартовый образ например в виде одного файла rootfs в формате squashfs)
2) И если вдруг, при очередном обновлении что то поломалось, то система гарантированно
оказывается в стартовом состоянии.
3) Обновления пишутся в дополнительную свободную область (диска или карты памяти) т. е.
не поверх, и если текущее обновление не работает, всегда можно по цепочке вернуться к
предыдущему.
4) возможно в ближайшее время я смогу этим заняться (сейчас мне с коллегами нужно за 3 месяца сделать очередной «Авиационный тренажер» — Авиа такси (понравилась фраза из wiki
два пилота и два пассажира или один пилот и три пассажира (т. е. пассажира сажаем на место пилота — прикольно)), и если получиться, то я смогу вернуться к просмотру «телевизора».
сделать следующее:
1) Всегда есть базовый (стартовый образ например в виде одного файла rootfs в формате squashfs)
2) И если вдруг, при очередном обновлении что то поломалось, то система гарантированно
оказывается в стартовом состоянии.
3) Обновления пишутся в дополнительную свободную область (диска или карты памяти) т. е.
не поверх, и если текущее обновление не работает, всегда можно по цепочке вернуться к
предыдущему.
4) возможно в ближайшее время я смогу этим заняться (сейчас мне с коллегами нужно за 3 месяца сделать очередной «Авиационный тренажер» — Авиа такси (понравилась фраза из wiki
два пилота и два пассажира или один пилот и три пассажира (т. е. пассажира сажаем на место пилота — прикольно)), и если получиться, то я смогу вернуться к просмотру «телевизора».
Получится надежная система. Если статья еще кого – то сподвигла на подобные желания, или появилась новая идея напишите комментарий, думаю всем будет интересен чужой опыт и другая точка зрения.
У нас используется следующий механизм, nand поделена на разделы (примерно):
uboot-kernel-upgrade-rootfs-overlay-data
Все разделы, кроме overlay и data, read only.
При обновлении перезаписывается kernel (по времени быстро, его образ 2-5 МБ), затем образ root записывается в раздел upgrade (по времени дольше — несколько десятков секунд, образ в 40 МБ), после успешной записи выставляется флаг для uboot и происходит перезагрузка. При перезагрузке происходит запись из upgrade в rootfs, обновляется флаг. При такой последовательности только отключения питания на этапе записи kernel может вызвать проблемы. Но на практике случается так редко, что можно пренебречь.
Из минусов — необходимость дублирования раздела rootfs.
Приведу еще такое интересное наблюдение по поводу обновлений. Обновление системы в OpenWrt происходит следующим образом — происходит копирование системных бинарников в RAM, затем chroot в RAM — система переключается на работу из оперативки, все разделы, в том числе и root, обновляются. Это отлично работает с nor spi-памятью. Но если надо обновить raw NAND и ubi, то такой фокус не прокатит — ядро не даст обновить раздел root. Для решения этой проблемы в OpenWrt добавили патчи в ядро и все работает. В некоторых же других больших коммерческих компаниях для решения этой же задачи используют вторую связку ядро+рутфс, чтобы можно было перезаписать основную систему. И нет, это не добавляет никакой стабильности, так как при пропадании питания устройство будет пытаться ломиться в основную рутфс, а не в ту, из которой необходимо обновляться.
uboot-kernel-upgrade-rootfs-overlay-data
Все разделы, кроме overlay и data, read only.
При обновлении перезаписывается kernel (по времени быстро, его образ 2-5 МБ), затем образ root записывается в раздел upgrade (по времени дольше — несколько десятков секунд, образ в 40 МБ), после успешной записи выставляется флаг для uboot и происходит перезагрузка. При перезагрузке происходит запись из upgrade в rootfs, обновляется флаг. При такой последовательности только отключения питания на этапе записи kernel может вызвать проблемы. Но на практике случается так редко, что можно пренебречь.
Из минусов — необходимость дублирования раздела rootfs.
Приведу еще такое интересное наблюдение по поводу обновлений. Обновление системы в OpenWrt происходит следующим образом — происходит копирование системных бинарников в RAM, затем chroot в RAM — система переключается на работу из оперативки, все разделы, в том числе и root, обновляются. Это отлично работает с nor spi-памятью. Но если надо обновить raw NAND и ubi, то такой фокус не прокатит — ядро не даст обновить раздел root. Для решения этой проблемы в OpenWrt добавили патчи в ядро и все работает. В некоторых же других больших коммерческих компаниях для решения этой же задачи используют вторую связку ядро+рутфс, чтобы можно было перезаписать основную систему. И нет, это не добавляет никакой стабильности, так как при пропадании питания устройство будет пытаться ломиться в основную рутфс, а не в ту, из которой необходимо обновляться.
Делаю прошивки для некоторого оборудования на основе OpenWRT и (меньше) Buildroot в том числе запускал их на оборудовании, для которого нет прошивок на основе Linux. С OpenWRT вообще всё просто с обновлениями — есть штатный механизм, если что, его можно переписать.
А что мешает в третьем случае проверить целостность rootfs1 RO? Ну, например, при заливке rootfs1 ro посчитать хэш и сохранить его u-boot enw, тогда можно будет его проверять, и если он битый, то выходить на скрипт u-boot для восстановления. Тогда получится тот же подход, что и в 2 =)
Ничто не мешает, просто это повлияет на время загрузки, особенно если сборка около 1Gb. Плюс усложнит логику, хеш обновленного образа нужно будет записывать в окружение u-boot из Linux, или придумывать логику определения того что образ залит новый из u-boot, c подсчетом его нового хэш.
Если уж речь идет о восстановлении, то зачем u-boot, здесь лучше подойдет ramdisk, а это вариант 2.
Если уж речь идет о восстановлении, то зачем u-boot, здесь лучше подойдет ramdisk, а это вариант 2.
Спасибо за статью, но есть вопрос,
Загрузчик следует хранить в надежном месте, на надежном накопителе, например в отдельной NOR или EEPROM микросхеме.. В малинке же нет этого на плате?
Полностью с вами согласен, загрузка должна быть очень быстрой, я когда Kodi 15.2 под yocto собирал для Raspberry Pi 3B, смог добиться скорости включения от подачи питания до появления kodi Меню за 12 секунд, а вот Kodi 17.6 уже тормозной, быстрее 18 секунд так и не получилось (это при 10 классе microSDHC карты)
Так в убунте ж, если она так нужна, там overlayroot есть из коробки…
Не всегда получается с помощью overlay fs настроить множество слoeв файловой системы, я например на работе вместе с коллегами остановился на следующем варианте: У нас две или три компьютерных стойки и при подаче питания один образ ОS раскидывается через pxe boot на 10 — 15 компьтеров, каждый комп выполняет свою задачу, и есть базовый squashfs образ и далее к нему навешивается через aufs еще два или три образа squashfs в зависимости от функции компьютера (дополнительные образы передаються не на все компы, а только на нужные, что ускоряет время загрузки всей стойки (максимум 2 минуты)) и далее еще навешивается слой верхнего уровня ext4 в виде одного файла, в который уже можно писать (read/write). И я смог подключить это только через AUFS. На мой взгляд офигенная штука, очень гибкая.
Недостатки этого подхода в отсутствии визуализации процесса и в очень ограниченных возможностях загрузчика, т.е. никакую сложную логику стандартными средствами не наворотить, если конечно же не придумать свою команду в u-boot (но это уже другой тип обновления, язык C великая сила)
Посмотрите barebox, он умеет выполнять shell-скрипты.
Очень хорошо, что упомянули о barebox, в чем то он лучше u-boot, но особой разницы нет, тем более не очень понятно насколько полно поддерживается периферия железа. Если производитель пилит u-boot в своей ветке, то патчи в barebox будут поступать с задержкой.
Shell в barebox, это хороший плюс, но одним shell сыт не будешь… Решение не поможет в задачах:
Shell в barebox, это хороший плюс, но одним shell сыт не будешь… Решение не поможет в задачах:
- где требуется отобразить прогресс обновления или ошибку на дисплее. А если еще интерактив нужен, то подавно.
- где требуется в WEB интерфейсе отобразить текущий статус обновления или выдать сообщение об ошибке,
- где требуется взаимодействие с ФС BTRFS, NTFS и т.д.
- где требуется поддержка VPN, FTP, HTTP, HTTPS например для загрузки образа восстановления,
- где требуется высокая секретность. Этот функционал из коробки не работает, обычно добавляют свой код, но это уже другая история.
Вот кстати очень похожая статья на хабре https://habr.com/ru/post/400011/
Sign up to leave a comment.
Опыт создания сборок Linux под одноплатники с поддержкой обновлений