На плате при использовании основной Nand flash для работы происходят сбои загрузки. Кто-нибудь сталкивался с подобным или все используют microSD? LOG в приложении.

Attachment file: uploads/forum/forum-VvUm0vLjgB-114778.zip

Плату как отключаете - просто питание убираете ? ubifs теоретически устойчива к сбоям питания но практически работу системы надо завершать корректно - halt или poweroff

Это проявляется и при корректном и при некорректном завершении работы.

+ в сборке STARTERKIT - завершение работы (poweroff) происходит без размонтирования томов и закрытия запущенных служб -> возможен обрыв записи на flash.

P.S. Сказали посмотреть в этой теме:

http://www.starterkit.ru/html/index.php?name=forum&op=view&id=23990&num=1

Сейчас изучаю, если что-то изменится отпишусь.

Вероятнее всего дело в количестве бедблоков в UBI разделе или косячках загрузчика ...
С год назад я изредка наблюдал подобные экземпляры (когда модуль могло зациклить на UBI: fixable bit-flip detected at PEB ... от загрузки к загрузке).
Сейчас перебрал все имеющиеся модули, ни одного с подобным эффектом не нашел, были некоторые с бедами, но там видимо всего один блок попадал и при первой загрузке загрузчик выдавал:

Цитата

UBIFS: default compressor: LZO
UBIFS: reserved for root: 1122259 bytes (1095 KiB)
Loading file 'uImage' to addr 0x11000000 with size 3716376 (0x0038b518)...
UBI: fixable bit-flip detected at PEB 5
UBI: schedule PEB 5 for scrubbing
Done

Судя по вашему логу, их попадается 3 и видимо от этого у него что то "съезжает" ...
Вероятнее всего увеличение объема загрузочного раздела приведет загрузчик в чувства.

Но все-таки правильнее будет пробовать новое ядро 3.10.17, субъективно, эти NAND работают в нем на порядок быстрее (видимо серьезно переработан механизм кеширования блоков) и монтирование UBI как в загрузчике, так и в ядре происходит "махом", так что если нет особых претензий к скорости загрузки (лишние пара секунд) - можно будет грузиться с основного раздела.

Цитата

Вероятнее всего дело в количестве бедблоков в UBI разделе или косячках загрузчика ...

Дело не в количестве бэдблоков а в кривой реализации поддержки MLC NAND в MTD, так как в убуте просто урезаная копия ядреной MTD - отсюда все те же проблемы + свои "тараканы", например при монтировании ubifs если есть бэдблоки убут убивает таблицу бэдов которую создало ядро пытаясь "исправить" ошибки хотя в режиме только чтение он должен просто пропустить блок который посчитал неисправным.

Цитата

например при монтировании ubifs если есть бэдблоки убут убивает таблицу бэдов которую создало ядро пытаясь "исправить" ошибки

Вот это уже плохо звучит. это означает, что загрузчик портит корректирующую информацию, есть возможность это исправить? Новое ядро как раз над этим работает?

Цитата

Новое ядро как раз над этим работает?

Как раз на нем я и столкнулся с этой проблемой
http://starterkit.ru/html/index.php?name=forum&op=view&id=23990&num=14#24530

в том буилдруте такое временное решение сделано по умолчанию

Цитата

Дело не в количестве бэдблоков а в кривой реализации поддержки MLC NAND в MTD, так как в убуте просто урезаная копия ядреной MTD - отсюда все те же проблемы ...

Помнишь, когда уперлись с MLC NAND при отладке imx6q, в итоге просто отключили использование таблицы бедов (непосредственно с nand проверяет блок) ... может в u-boot есть такая же "кнопка" ...

Помню - только наоборот, таблица хранится в nand, а при старте OOB не сканируется. У MLC очень большой размер erase block страниц и в OOB просто не остается места для статусной информации - она вся занята кодом для коррекции ошибок.

&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand_oem>;
nand-on-flash-bbt;
status = "okay";
};

http://lxr.free-electrons.com/source/drivers/mtd/nand/gpmi-nand/gpmi-nand.c?v=3.10#L1545

Цитата

if (of_get_nand_on_flash_bbt(this->dev->of_node))
chip->bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;

http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_bbt.c?v=3.10#L37

Цитата

If the NAND controller needs the complete OOB area for the ECC information then the option NAND_BBT_NO_OOB should be used (along with NAND_BBT_USE_FLASH, of course): it moves the ident pattern and the version byte into the data area and the OOB area will remain untouched.

только если включить подобную опцию в убуте imx6 (не знаю как с другими процессорами), убут виснет намертво.