После тестирования очередной партии SK-iMX6S-OEM модулей, выяснилось, что текущая схема загрузки ядра приводит к "угрожающему" проценту брака.
Чтобы этого избежать и сделать процесс загрузки более надежным (в случае возникновения дополнительных Bed блоков в партиции хранения ядра) изменили механизм загрузки ядра.
Ранее, ядра хранились в не форматированной области NAND flash и считывались u-boot в RAW режиме с указанием явных адресов и размеров.
Сейчас, партиции хранения ядра объеденены в одну и на ней создана дополнительная UBI ФС партиция (если хранить в основной ФС, процесс загрузки существенно замедлится, т.к. монтирование больших разделов UBI довольно долгое занятие, особенно в контексте загрузчика u-boot) с которой загрузчик u-boot читает ядро.
Пришлось внести изменения в NAND партиции ядра и перейти на новую версию u-boot, переписать скрипты обновления системы.
Так же теперь нельзя обновить ядро из u-boot, зато при запущенной системе это стало сделать гораздо проще (просто скопировать файлы в /boot папку).
Все исходные тексты и виртуальная машина обновлены на ФТП.
UPD 12.09.2017
Как ни печально, но метод с загрузочным UBI разделом себя плохо зарекомендовал, со временем u-boot не редко отказался читать ядро.
А т.к. за это время MLC NAND флешки пропали с нашего рынка (сейчас везде ставим SLC флешки), то исчезла и проблема породившая первоначальное изменение схемы загрузки (кривая поддержка MLC в u-boot).
Начиная со сборки "buildroot-2017.08 на базе ядра 4.1.15-2.1.0 для i.mx6" вернули обратно механизм загрузки непосредственно с секторов NAND флешки.
Добрый день.
А не маленьким получается раздел в 16МБ?
Если я правильно понял лог, то ubifs не хватает места или у меня флешка сильно "плохая" стала?
Поможет увеличение размера раздела допустим до 32, 64 мегабайт?
Это конечно плохо, что придется отходить от родного разбиения.
И еще вопрос - подскажите, плиз, кто создает ноды для /dev/ubi0, ubi1....какое-то правило udev?
Посмотреть на родном дистрибутиве уже не могу - пока отлаживал "восстановление" системы, первая удачно выполненная команда была flash_erase :)
Jan 1 00:00:10 buildroot user.notice kernel: UBI: attaching mtd0 to ubi0
Jan 1 00:00:10 buildroot user.notice kernel: UBI: scanning is finished
Jan 1 00:00:10 buildroot user.warn kernel: UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handl
ing, reserved 123, need 159
Jan 1 00:00:10 buildroot user.notice kernel: UBI: attached mtd0 (name "boot", size 16 MiB) to ubi0
Jan 1 00:00:10 buildroot user.notice kernel: UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jan 1 00:00:10 buildroot user.notice kernel: UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jan 1 00:00:10 buildroot user.notice kernel: UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
Jan 1 00:00:10 buildroot user.notice kernel: UBI: good PEBs: 127, bad PEBs: 1, corrupted PEBs: 0
Jan 1 00:00:10 buildroot user.notice kernel: UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
Jan 1 00:00:10 buildroot user.notice kernel: UBI: max/mean erase counter: 1/1, WL threshold: 256, image sequence number:
998430147
Jan 1 00:00:10 buildroot user.notice kernel: UBI: available PEBs: 0, total reserved PEBs: 127, PEBs reserved for bad PEB
handling: 123
Jan 1 00:00:10 buildroot user.notice kernel: UBI: background thread "ubi_bgt0d" started, PID 143
Jan 1 00:00:10 buildroot user.err kernel: UBIFS error (pid 144): ubifs_mount: cannot open "ubi0:boot", error -19
07.02.2014 16:13 
12.09.2017 18:59
