Получится надежная система. Если статья еще кого – то сподвигла на подобные желания, или появилась новая идея напишите комментарий, думаю всем будет интересен чужой опыт и другая точка зрения.
Многие мучаются с yocto, т.к. очень мало по ней информации. Поддерживаю автора, спасибо что осветили не простую тему. Новичкам будет полезна эта статья.
Очень хорошо, что упомянули о barebox, в чем то он лучше u-boot, но особой разницы нет, тем более не очень понятно насколько полно поддерживается периферия железа. Если производитель пилит u-boot в своей ветке, то патчи в barebox будут поступать с задержкой.
Shell в barebox, это хороший плюс, но одним shell сыт не будешь… Решение не поможет в задачах:
где требуется отобразить прогресс обновления или ошибку на дисплее. А если еще интерактив нужен, то подавно.
где требуется в WEB интерфейсе отобразить текущий статус обновления или выдать сообщение об ошибке,
где требуется взаимодействие с ФС BTRFS, NTFS и т.д.
где требуется поддержка VPN, FTP, HTTP, HTTPS например для загрузки образа восстановления,
где требуется высокая секретность. Этот функционал из коробки не работает, обычно добавляют свой код, но это уже другая история.
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 это будет лучший выбор.
За все малинки отвечать не берусь, но в документе Raspberry-Pi-Schematics-R1.0.pdf ее не нашел. Пришлите схему, я посмотрю.
Поймите меня правильно, я специализируюсь на ПО для разработанных плат компании, в которой работаю, там малинки не используются.
Ничто не мешает, просто это повлияет на время загрузки, особенно если сборка около 1Gb. Плюс усложнит логику, хеш обновленного образа нужно будет записывать в окружение u-boot из Linux, или придумывать логику определения того что образ залит новый из u-boot, c подсчетом его нового хэш.
Если уж речь идет о восстановлении, то зачем u-boot, здесь лучше подойдет ramdisk, а это вариант 2.
Докер это отличное и модное решение, которое например ставит крест на костылянии
в 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, т.к. экономится много времени на разработку.
1. 256Мб NAND дешевле чем 4Gb emmc. Меньше 4G — emmc не производится. Если не
требуется большой объем, зачем переплачивать.
2. Архитектура NAND прозрачна.
Каждый производитель emmc использует свои алгоритмы, которые закрыты, это черный ящик хранящий сюрпризы в отличие от прозрачного NAND.
NAND имеет кучу минусов, которые можно обойти, в отличие от черного ящика emmc.
Nano pi не тестировал, по характеристикам приличное железо.
Но нет меганадежного накопителя для загрузчика. Загрузчик придется размещать в emmc с основной сборкой, плюс двусторонний монтаж, поэтому на плату пузом не посадишь, только через разъем.
По поводу UPS, то эта задача для stm32. Лично я этим не занимаюсь, но могу спросить у коллег, сформулируйте задачу в личку, я передам.
Требования к начинке зависят от задачи.
Мин требования 64Мб DDR2, 256Мб ROM (любого типа), CPU 500MHz.
Изначально у меня была задача, которая требовала нечто готовое. Я поглядывал в сторону openwrt, понял что это проект для создания роутеров и не более, шаг в сторону, начинаются квесты и приключения.
Поэтому решил, что проще разработать свой проект, чем тащить пласт неизвестного для меня кода, с неизвестными ошибками и подводными камнями. Все хорошо на словах, его рекламируют, у него большое сообщество, много отличных роутеров на его базе создано, но вот например сколько нужно потратить времени, что бы из него сделать видеодомофон, сколько нужно времени что бы весь его WEB интерфейс переделать под свои задачи да так что бы ничего не ломалось, хороший вопрос.
Плюс как можно гарантировать стабильность решения не зная его на 100%. Поэтому было принято решение, разработать свой проект в котором перечисленные вопросы отпадут сами собой.
Что выбрать, это дело вкуса. Если вы новичок, то советую raspberry. Если профи, то берите смело любой одноплатник под ваши нужды. Лично я на orangepi zero и lichee pi собирал и использовал yocto, все как по маслу собирается и заводится.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Shell в barebox, это хороший плюс, но одним shell сыт не будешь… Решение не поможет в задачах:
2. Ошибки NAND известны, к ним можно подготовится. С точки зрения блочного доступа, emmc лучше чем NAND, экономится программистское время, не нужно заморачиваться с UBIFS, e2fs и подобными узкоспециализированными ФС, не нужно заботится от карте битых секторов, не нужно устраивать танцы c несовместимостью ECC и т.д. Поэтому ее используют, про ее удобство я не спорю, и еще раз подчеркиваю, emmc удобнее NAND…
Я не готов в двух словах рассказать как работает emmc, нет времени, да и информации в гугле достаточно. Главное это то что emmc в фоне переносит сектора у которых сработал счетчик числа записей в другое менее зашкварное место. Физические сектора emmc размером например 1Мб, требуют время для переноса, плюс перед переносом требуется очистить сектор назначения. И вот представьте что будет если в этот момент вырубится питание. Я не говорю что emmc нельзя использовать, его весь мир использует. Просто хочу подчеркнуть небольшое преимущество NAND выраженное в простоте и открытости в отличие emmc, если проект имеет сборку размером 60Мб, то NAND это будет лучший выбор.
Поймите меня правильно, я специализируюсь на ПО для разработанных плат компании, в которой работаю, там малинки не используются.
Если уж речь идет о восстановлении, то зачем u-boot, здесь лучше подойдет ramdisk, а это вариант 2.
в 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, т.к. экономится много времени на разработку.
требуется большой объем, зачем переплачивать.
2. Архитектура NAND прозрачна.
Каждый производитель emmc использует свои алгоритмы, которые закрыты, это черный ящик хранящий сюрпризы в отличие от прозрачного NAND.
NAND имеет кучу минусов, которые можно обойти, в отличие от черного ящика emmc.
Но нет меганадежного накопителя для загрузчика. Загрузчик придется размещать в emmc с основной сборкой, плюс двусторонний монтаж, поэтому на плату пузом не посадишь, только через разъем.
По поводу UPS, то эта задача для stm32. Лично я этим не занимаюсь, но могу спросить у коллег, сформулируйте задачу в личку, я передам.
Мин требования 64Мб DDR2, 256Мб ROM (любого типа), CPU 500MHz.
Изначально у меня была задача, которая требовала нечто готовое. Я поглядывал в сторону openwrt, понял что это проект для создания роутеров и не более, шаг в сторону, начинаются квесты и приключения.
Поэтому решил, что проще разработать свой проект, чем тащить пласт неизвестного для меня кода, с неизвестными ошибками и подводными камнями. Все хорошо на словах, его рекламируют, у него большое сообщество, много отличных роутеров на его базе создано, но вот например сколько нужно потратить времени, что бы из него сделать видеодомофон, сколько нужно времени что бы весь его WEB интерфейс переделать под свои задачи да так что бы ничего не ломалось, хороший вопрос.
Плюс как можно гарантировать стабильность решения не зная его на 100%. Поэтому было принято решение, разработать свой проект в котором перечисленные вопросы отпадут сами собой.