Чем и как прочитать образ из NAND?, есть плата на процессоре TI AM1705 Опции

[no_d@t@]

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

Итак вопрос: собрал свою плату на процессоре 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...

[no_d@t@]

Воспользовался 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 и загрузиться с нее.


Сообщение отредактировал no_d@t@ - Jan 16 2013, 10:57

[_3m]

Воспользовался dd.
...
Получил на хосте желаемый образ NAND размером 256 Мб. На днях принесут программатор, попробую зашить в чистую новую флешку mtdblock0.bin и загрузиться с нее.

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

[samike]

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

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

[IgorKossak]

А расскажите, почему jffs2 / ubifs стукнут граблями?

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

[alx2]

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

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

[_3m]

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

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

[alx2]

Бэды могут появляться во время работы, софт их на лету помечает и обходит.

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

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

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

[samike]

Уточните, пожалуйста, какой именно софт их помечает и обходит

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

Мне вообще такой подход (модификация образа файловой системы в целевой плате) кажется странным.

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