Запись jffs2 UBOOT-ом в nand, Постоянный принт собщений Magic bitmask XX not found XX & Empty fl Опции

[intel-DX]

Добрый день.

Столкнулся с проблемой записи jffs2 имджа в nand через u-boot. Сама запись проходит без проблем. Но при работе вылетают сообщения:

Empty flash at ххх ends at ххх
JFFS2 notice: (441) check_node_data: wrong data CRC...
jffs2_scan_eraseblock(): Magic bitmask хх not found at ххх instead


Nand у меня MT29F2G08.
– Page size x8: 2112 bytes (2048 + 64 bytes)
– Block size: 64 pages (128K + 4K bytes)
– Plane size: 2 planes x 1024 blocks per plane

jffs2 делаю в buildroot,
"Flash Type: NAND flash with 2kB Page and 128 kB erasesize"

В у-буте пишу имдж так:
"usb start; "
"usb reset; "
"usb 0 0x70000000 roofs.jffs2; "
"nand erase.chip; "
"nand write 0x70000000 0x800000 $filesize; "

Строка загрузки ядра: root=/dev/mtdblock1 rw rootfstype=jffs2

CPU: AT91SAM9G45
U-boot: 2012.07
Kernel: 3.2.6
buildroot: 2012.08

Буду рад любой информации.
Спасибо.

[xor.kruger]

Вполне может быть что некорректно читаются данные с юсб-накопителя.
Для того что бы убедится в этом сравните две области памяти командой cmp, ну или на крайний случай залейте образ в ОЗУ через ethernet, а потом уже во флешку.

[kurtis]

Такое происходит на всех платах? Или только на одной?

[Drozd2]

Сталкивался с таким в двух случаях. Первое, если перед записью jffs2 не стереть flash полностью. Второе, если система используется для отладки, и во flash периодически записывается новое приложение. Или просто что-то записывается с переходом на новый блок памяти.
В обоих случаях, если система грузится, то лучше не обращать внимания на такие сообщения. В законченной системе с отлаженным приложением после полного стирания flash перед записью jffs2 подобных сообщений не будет. Если не получается не обращать внимания и остается осадок, то лучше перейти на ubifs.
P.S. Писано для запускающейся системы. После повторного прочтения темы затерзали смутные сомнения. У Вас система запускается?

Сообщение отредактировал Drozd2 - Feb 7 2013, 20:04

[Hoodwin]

Недавно ковырялись с этим, пока приживляли U-Boot к архитектуре C6000. Навскидку могут быть две причины такого поведения.
1) Раскладка OOB в NAND не совпадает между драйвером mtd устройства в U-Boot и ядре линукс. В итоге получается, что JFFS2 не видит свои метаданные в OOB правильно. Но это маловероятно, если из U-boot пишется образ раздела, созданный с помощью mkfs.jffs2, поскольку в этом случае в OOB изначально ничего не пишется, кроме, возможно ECC. Но в любом случае, это стоит проверить.
2) В драйвере и ядре отличается режим поддержки ECC. В этом случае получается, что записанный образ читается с NAND, но дает расхождение в ECC, затем происходит коррекция данных по ECC, и это приводит к порче CRC в JFFS2. Так что поддержку ECC тоже стоит проверить.