Уважаемые форумчане! Есть несколько вопросов по bad-блокам в NAND.
1) Изначально может быть некоторое число bad-блоков, информация о них присутствует в самой микоросхеме. Если эта информация будет утеряна в дальнейшем, возможно ли как-нибудь ее восстановить, например стиранием/записью/верификацией всех блоков?
2) По мере использования могут появляться новые bad-блоки. Они появляются только при стирании/записии, или могут появиться и при чтении?
1) Linux по умолчанию с SLC использует информацию в OOB, сканирует NAND при каждом старте и создает таблицу, потом синхронизиует ее с имеющейся таблицей в нанде (если такая имеется) или создает новую. На MLC с тем что встречался - OOB используется только для хранения ECC, при старте NAND не сканируется, BBT создается при форматировании.
2) не знаю, лучше наверно на форуме производителей NAND чипов спрашивать :)
Они обещают для первого блока 1К стираний/записей. Значит, туда можно поместить начальный загрузчик, и даже будет гарантированный маневр для его обновления.
Основной бинарник (будь то ядро линукса или standalone) можно разместить в любой части NAND. Допустим, что при обновлении прошивки один из этих блоков портится так, что ECC уже недостаточно. Тогда мы должны переписать бинарник в другие блоки и заодно еще поменять начальный загрузчик, чтобы он знал и умел работать с новым местоположением бинарника.
Правильно понимаю механизм хранения и обновления прошивок?
Вы мух от котлет отделяйте :) в стандалонах скорей всего ничего хорошего вы не сделаете а вот в u-boot Linux можно и с фс читать, а там логическая структура с bad eraseblocks handling и wear-leveling имеются. От процессора тоже зависит - насколько там "умный" встроенный начальный загрузчик.
Согласен, в случае с linux можно воспользоваться u-boot и хранить ядро в ФС.
А в моем случае будет i.mx287 и приложение под ECOS (статически линкуется в единый бинарник). Критично время старта и жесткий реал-тайм, поэтому приходится отказываться от linux.
я бы поступил для оптимизации и упрощения так:
- оставить Uboot в качестве вторичного загрузчика, выключив весь функционал и оставив три компоненты
-- ветка загрузки стендалоне
-- ветка поиска обновления с указанного источника
-- ветка перезаписи фирмваре(стендалоне)
вариант сложнее - повторить подвиг по написанию своего аналога юбута, с вышеперечисленными поддержками, разумеется подсматривая в сорцы юбута..
гуглиться по linux fast boot
на самом деле 300мс это достаточно сложно на мой взгляд... ядро очень ужато должно быть, вырезано всё лишнее, но тем не менее... какое время максимально возможно уделить загрузке в вашем случае?