Так и надо делать. Всегда, когда без ОС. По дефолту.

Вот не надо, ydevconfig + ymount + ywrm отлично работают с yaffs2 в u-boot
А с LogFS, понятно, еще просто не успели.

Правильно. Только Yaffs2!
А все остальное назвали просто чтобы показаться умнее, не так ли?
Мы ж здесь не первый год.

Да-да. А "ubifssave" по аналогии с "ubifsload" добавить - сутки работы (естественно, если смотришь на код ю-бута не как баран на новые ворота). Экая мегасложность. Вот именно, что не первый день мы тут.

Понимаете, у меня есть вредный бзик.
Я крайне редко использую сторонние библиотеки,
особенно если не понимаю, как она работает.
И не пользую ОС для контроллеров, не сталкивался пока с необходимостью.
Поэтому меня интересуют приципы работы, а ФС и сам напишу.
Не впервой

Этот ю-бут уже считай мертвец.
Щас Freescale сделает че-нить на Cortex-M7 и приделаем мы туда универсальный лодер на базе MQX с любых коммуникационных каналов.



Нет, не понимаю.
Такого не может быть в природе.
Люди которые поняли как работает Yaffs2 и портировали ее ну никак не могут не использовать ОС.
Потому что ОС это реальная экономия времени.

Ну а мы научили грузить линукс напрямую x-loader (думая только о скорости старта устройства в целом, на Cortex-A8), так что у каждого свой путь убить юбут. Но это не значит, что он совсем мертвец. Он бывает еще нужен... В том числе, и как пример работы с файловыми системами без ОС.


Зато, разбазаривание ресурсов. Так что вопрос крайне спорный. Где надо сэкономить неделю разработки - да, ОС очень пригодится. А где надо сэкономить последние 10 центов стоимости ресурсов - ОС категорически вредна. Так что, не надо все подводить под одну гребенку. Каждому решению свое место. Причем, очень много решений, где, сначала, в убыток себе, но быстро, делается решение на базе ОС, а затем, за три-четыре месяца, делается уже массовое решение без ОС, которое окупает и расходы на первое, быстрое и расточительное решение, и приносит прибыль.

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

PPS.
Я сам отношусь к поклонникам решений без излишеств, навроде ОС и прочих внешних либ, и аккуратной экономии ресурсов - применения наиболее дешовой комплектации и минимизации цены BOM. Но вполне себе понимаю, что бывают случаи, когда надо наплевать на цену, и сделать быстро. И вот тогда...

От вас ли я слышу сделать быстро не жалея ресурсов?
кстати что такое ВОМ?

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

А че тема? С темой все ясно.
Все wear leveling движки используют динамическое выделение памяти.
Эти механизмы выделения всегда требуют портирования.
Я бы даже может заплатил тому, кто точно скажет слолько же памяти в пике может забрать тот или иной движок.
Так что только ось и помогает в этой неопределенности с ее сервисами постановки выделения памяти в очередь и контроля за пулами памяти.

Потому и говорю уверенно, кто хочет использовать FS под NAND тот точно подсядет на RTOS.

Да и самые доступные движки под NAND это FTL в составе RTOS vxWorks (в хранилище кстати лежит) и FFS в составе RTOS MQX (бесплатно).

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

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

Да вот один из примеров приведу. Делали когда-то один девайс по некоей специфической обработке речи. Первую версию сваяли на плавучем TMS под управлением DSP/BIOS, чтобы просто успеть в срок - модель из матлаба за день переложили на систему на TMS320C6713. Получили с первой партии некие убытки, так как дорогая это платформа, не укладывающаяся в бюджет. Зато сделали именно мы, а не соседи. Затем, пока заказчику хватило первой сотни девайсов, переработали на дешовый TMS320VC5501, в который уже не умещается RTOS, уместив туда на голом ассемблере все тоже самое, но без ОС, и без ухудшения потребительских свойств. В результате на следующих партиях окупили и расходы на первую, убыточную, и получили прибыль. И никакой левый софт там не может обеспечить добавочную стоимость, так как стоимость прописана в контракте, как и требуемая функциональность.
Еще сколько хотите примеров в крупносерийке, где поставить процессор на 10 центов дешевле принесет либо прибыль в $100K, либо конкурентное преимущество в цене. Зато в этот процессор ОС уже не влезет, а функциональность всего необходимого он обеспечит, на грани своих ресурсов с совсем малым запасом.

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


Bill Of Materials - список компонентов

Странный пример.
На TMS320VC5501 RTOS помещается, да еще и не слабая.

А не поставили вы ее туда, потому что TI на халяву не предлагал тогда, а купить денег не было.
Но поэтому функциональность вашего дивайса стала урезанной. И вы потеряли кокое-то количество денег из-за потери некоторых потребительских сегментов.
Вот так мне эта история видится.



Может с конкретными задачами и конкретными дивайсами это и так.
Но на конкретных задачах далеко не уедешь.
Рынок требует решения непредсказуемых задач.

Во первых, да, RTOS влезает, но тогда не влезает функциональность. А если влезает функциональность - причем, даже написанная на С не влезает, а только на ассемблере, и с трудом, то RTOS никак не влезает.
Во вторых, у нас DSP/BIOS была в полном объеме для всех нужных семейств (я же, заметьте, написал прямо - первая версия, убыточная, была сделана на ней).
В третьих, функциональность была полная и соответствующая заказу. Других же потребительских сегментов изделие не имеет, если его начать продавать "на сторону", то незамедлительно можно уехать в длительную командировку в места, не столь отдаленные.

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


UPD
Вдогонку, добавлю. Да, RTOS уже внатяг влезала в TMS320VC5502, но это +$2 к себестоимости, что при общей себестоимости девайса в $10-12 совершенно недопустимо, лишь ради того, чтобы ради непонятных понтов применить RTOS.



Не согласен. Я, например, работаю в основном на конкретных задачах, и наибольшее время из всей работы занимает именно минимизация себестоимости изделия - оптимизация схемы и минимизация занятых программой ресурсов. Вплоть до разработки ASIC под задачу уже с минимизацией его площади (а это уже не две-три добавочные недели на софт без ОС, а полгода минимум), чтобы уменьшить цену. Да, есть и исключения, когда надо "сделать быстро и пофигу сколько оно стоит", но это, скорее, исключение, среди реальных случаев, с которыми я сталкивался. Основная же работа, как правило, сводится к "впихнуть невпихуемое".

PS
Зачем тут этот бессмысленный спор? Я также знаю немало успешных проектов, где вполне допустимо практически без потерь в прибыли добавить лишних ресурсов и упростить себе жизнь с использованием левых библиотек и ОС. Но это не отменяет и другой доли проектов, где это сделать нельзя. Поэтому я отлично понимаю желание автора запустить FS в NAND без ОС, тем более, сам когда-то это делал, правда не в NAND, а в датафлешах, изобретая свою простую FS, удовлетворяющую задаче, с информацией о файлах только в OOB, и реализуя все это полностью на ассемблере, чтобы оно хоть как-то влезло в имеющийся ресурс.

Вот только не смешите и не называйте DSP/BIOS тех лет RTOS.
Надо так понимать что с RTOS у вас тогда вообще опыта не было.



Да ну!
Приблизительно в те же годы мы поднимали платформу GSM модема.
Его вся себестоимость была в тех же 12$.
На RTOS-ах никто не экономил.

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


DSP/BIOS тех лет была вполне себе продвинутая для тех лет RTOS, из того выбора, что вообще можно было запустить на TMS320C55xx. Видимо, Вы с ней тогда дела не имели.

Естественно не имел. Подбирать и иметь дело со всем мусором который выложен с сети не хватит никакой жизни.
Достаточно было ознакомится с предлагаемымии DSP/BIOS сервисами и все стало ясно.

Но может я что то упустил и в DSP/BIOS есть уникальные файловые системы особенно для NAND?

Мой подход такой: сначала выбрать софт, а потом железо.
Общеизвестно, что софт в разработке самый трудоемкий процесс и ему естественно отдавать приоритет если живете за счет разработок.

Аргументы вроде того, что вот сижу и схемотехнически тут минимизирую BOM за счет отказа от сотни другой килобайт памяти тоже меня не убеждают.
Если бы так переживали за BOM то в первую очередь следили бы за курсом валют и логистикой.
Одно суточное плавание соотношения курсов и запасов в стоках меняет мои BOM на десятки процентов.
Это явление на порядок сильнее всех потуг экономить BOM за счет пары компонентов.