Да, печально. Казалось бы универсальная задача всеобщей востребованности, но смысла в её решении мало, ибо считанный образ с высокой вероятностью при записи попадёт в сбойные участки NAND .
Поэтому (по моему скромному разумению) готового Вы не найдёте.

Копируют систему по частям:
вначале в NAND складывают несколько копий u-boot - в надежде, что хотя бы одна копия окажется годной,
затем - ядро, файловую систему и остальное.

Я не утверждаю, что это единственный способ. Так делают - ничего личного.
Конкретные платформы для этого комплектуются специализированным софтом, при этом требования к железу тоже существуют.
(Пример: http://e2e.ti.com/support/dsp/sitara_arm17.../t/159131.aspx)


Несколько озадачили слова от IgorKossak


NAND делают ради удешевления хранения бит информации. Просто.
NAND невозможно поставить гарантированно без "некоторого процента", ибо уже при перевозке с завода в магазин число сбойных бит может измениться
Да, на заводе NAND тестируют и обнаруженные сбойные блоки помещают в список. Если список короткий, то - в магазин, иначе - в утиль.



Вы, вероятно, счастливый человек. У меня все NAND - BGA...

То же самое я и хотел сказать. Может не совсем удачно вышло.
По теме, у меня процедура записи такая:
1. загружается в озу U-boot (версия для озу) и запускается;
2. загружается и программируется в НАНД версия U-boot для прошивки;
3. подобнейшим образом загружаются и прошиваются остальные разделы: u-boot-env, splash, kernel, rootfs.
Не совсем оптимально, но другого способа пока у меня нет.

Уточните, пожалуйста, какой именно софт их помечает и обходит - драйвер, лежащий "ниже" /dev/mtdblock*, или софт файловой системы, лежащий "выше"? Верно ли я понял, что именно софт файловой системы?


Мне вообще такой подход (модификация образа файловой системы в целевой плате) кажется странным. Причем странным дважды.
1. Сначала Вы создаете файловую систему без нужного приложения (а что там тогда есть?), записываете ее в ПЗУ платы, потом устанавливаете приложение, после чего считываете образ FS из платы обратно для последующего тиражирования. Не логичней ли будет сразу установить все нужные пакеты, включая ваше приложение, и сразу сгенерировать образ файловой системы, готовый к производству?
2. Если уж по каким-то непонятным мне причинам Вы не хотите (или не можете) сразу генерировать образ FS с тем содержимым, которое требуется, и задача стоит именно в модификации уже имеющейся FS, не лучше ли будет "развернуть" содержимое FS на персоналке, выполнить необходимые модификации (доустановить какие-то пакеты) и затем заново сгенерировать новый образ? И не связываться вообще с NAND-ПЗУ и целевым устройством вообще...

Меня также интересует этот вопрос ...


Да нет, я не собираюсь модифицировать образ файловой системы.
Пока остановился на варианте, подобном тому, что описал IgorKossak.

Требовать от софта файловой системы отвечать за bad blocks носителя бессмысленно.
В HDD листы бэдов пишутся контроллером во флэш-память (т.е. более другой носитель). Полагаю, в NAND сделано примерно также - контроллер пишет ошибки большой дешёвой памяти в более дорогую, но независимую память (на том же кристалле). Наружу контроллер предоставляет линейный массив, но не обязательно одинаковой длины - с этим и связаны неприятности с переносом системы посредством dd, имхо.

Нету там "более дорогой независимой" все в нанд!
"финские студенты" с вами не согласны и bad blocks появляющиеся вследствие износа помечает фс.
Курите Bad_Block_table_support

Помечает бэды в частности:
drivers/mtd/ubi/wl.c
fs/jffs2/erase.c

Еще посмотрите drivers/mtd/nand/nand_bbt.c

Значит опять склероз (касательно размещения флэша другого свойства для bad blocks на том же чипе).
В позапрошлом году развлекался, вытаскивая инфу с usb-шных флэшек. В приведённой Вами ссылке следующий параграф описывает обычный для них случай.
А по граблям с хранением bbt носителя на нём же производители hdd уже ходили.