Может быть туплю, сильно не пинайте

Итак вопрос: собрал свою плату на процессоре Sitara AM1705, в NAND по UART записал U-boot, затем из под U-boot прошил в NAND ядро Linux, файловую систему, затем из под Linux записал в NAND свое приложение, протестировал работоспособность.
Теперь мне нужно прочитать из NAND полученный образ (U-boot + Linux + rootFS + приложение) и записать этот образ в другие платы. Типовая вобщем-то задача.
Каким образом можно вычитать образ из NAND?
Подозреваю, что мне потребуется Code Composer Studio и JTAG?
Или как-то еще?

П.С.: До того как перейти на Texas, работал с ARM9 от Atmel, так там была прекрасная утилита SAM-BA. Она позволяла (в удобном графическом режиме) записать/прочитать флеш память по USB...

Сам u-boot не позволяет это сделать?
http://wiki.starterkit.ru/uboot

Там встречаются команды.
nand read - <адрес> <смещение> <размер>
nand write - <адрес> <смещение> <размер>

С помощью u-boot я вроде как могу вычитать содержимое NAND в ОЗУ.
А что дальше с этим делать? Как передать прочитанное на хост?
Вопросы задал навскидку, еще не разбирался. Завтра приду на работу, почитаю.

А это уже от вашей платы зависит. Какие интерфейсы у нее есть? RS232? USB? Слот SD-карты?
В зависимости от того, куда Вы хотите данные из ОЗУ вывести, в u-boot должны быть соответствующие средства.
Например вывести в компьютер через RS232 можно по протоколу kermit командой saves...

Кстати, проще наверное из линукса скопировать разделы флешки (u-boot, его переменные, линукс и файловую систему) с помощью dd куда Вам надо, а потом склеить в единый образ...

Интерфейсы - RS232 и Ethernet.


Так почему-то не получилось, saves не удалось связаться ни с HyperTerminal, ни с ZOC. Хотя помнится, что loadb без проблем работала с HyperTerminal.


А вот это, пожалуй, действительно поможет. Буду пробовать.
Спасибо!

Воспользовался dd.
Описал всю NAND (256 Мб) как один раздел: mtdparts=davinci_nand.1:0x10000000@0x0(nand_all)ro
Загрузился, подмаунтился к хосту по nfs и выполнил:
dd if=/dev/mtdblock0 of=/nfs/mtdblock0.bin
Получил на хосте желаемый образ NAND размером 256 Мб. На днях принесут программатор, попробую зашить в чистую новую флешку mtdblock0.bin и загрузиться с нее.

Какую фс вы используете?
У меня такое ощущение что jffs2 / ubifs вас мощно стукнут граблями по лбу после того как вы в другой экземпляр нандфлэш зальете считанный образ.

А расскажите, почему jffs2 / ubifs стукнут граблями?
Просто стоит похожая зачача - прочитать образ из NAND и залить в другие платы.

патамушта NAND flash
нужно не смнимать дамп раздела а получать образ фс

Дело вовсе не в файловых системах, а в том, что NAND flash (ради удешевления, вероятно) поставляется с некоторым процентом сбойных секторов, которые при производстве соответствующим образом помечены. У каждого экземпляра микросхемы количество и расположение этих секторов разное. Дальше, думаю, всё понятно.

Печально.
Так как же все таки корректно прочитать из NAND необходимый образ (U-boot + Linux + rootFS + приложение), чтобы записать этот образ в другие платы?

Мне казалось, что ремаппинг сбойных секторов выполняется драйвером, лежащим "ниже" чем /dev/mtdblock*. Иными словами, блоки, доступные через /dev/mtdblock*, уже гарантированно "хорошие". Я неправ?

Как все запущено!
Вы правы, но частично. Бэды могут появляться во время работы, софт их на лету помечает и обходит.
Однако главная проблема не в этом. Проблема в том что в нанд есть Spare area в которой хранится корректирующий код, кроме того например jffs2 в одной из конфигураций хранит там метаданные, образ без метаданных можно сразу отправлять в /dev/null потому что он не смонтируется. Из-за корректирующего кода стертый блок и блок в который записаны 0xff совершенно разные вещи.
Еще раз повторю: из нанд надо снимать образ утилитой которая понимает тип фс. Писать тоже утилитой от используемой фс.

Не понял, только образ ФС нужно вычитывать утилитой, которая понимает тип ФС?
Или u-boot и kernel тоже?
Думаю, что u-boot и kernel можно безболезненно вычитать из NAND с помощью dd, а вот с ФС действительно непонятно.
Может nand dump подойдет?

Вобщем, процесс автоматизации прошивки большого количества плат пока видится таким:

- U-boot заливаем в NAND с помощью программатора,
- устанавливаем м/сх NAND на плату,
- с помощью скрипта (например из под ZOC) общаясь с U-boot по tftp заливаем в NAND ядро и ФС (используем nand write),
- ручками, уже из под linux, пишем в устройство свое рабочее приложение.

может быть можно все образы сразу ( U-boot, ядро и ФС) залить в NAND по определенным адресам с помощью программатора?
потом установить м/сх NAND на плату и ручками, уже из под linux, записать в устройство свое рабочее приложение.

Да, печально. Казалось бы универсальная задача всеобщей востребованности, но смысла в её решении мало, ибо считанный образ с высокой вероятностью при записи попадёт в сбойные участки 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 уже ходили.