ucLinux + NAND Flash K9F1G08 Опции

[yurmala]

Приветствую!
Отладочная плата EA LPC1788.
Пытаюсь на ucLinux завести NAND FLASH Samsung K9F1G08 для дальнейшего использования с JFFS2.
Подключение на плате стандартное - через 8-бит шину данных.
В u-boot (от lpcware) драйвер прекрасно работает с NAND. Там же с помощью mtdparts разбиваю на партиции, формирую bootargs с параметром
mtdparts=...
Вот кусок конфига из u-boot:

Код

#define CONFIG_JFFS2_CMDLINE
#define MTDIDS_DEFAULT      "nand0=nand"
#define MTDPARTS_DEFAULT   "mtdparts=nand:128k(env),4m(kernel),-(rootfs)"

Ядро успешно грузится с NAND.
А вот в самом ядре не получается подключиться к этой NAND.
в конфиге ядра подключены опции связаны с MTD (MTD, MTD_PARTITION, MTD_CHARACTER_DEVICE, MTD_BLOCK_DEVICE, MTD_NAND...).
Но в логе загрузки ядра вообще ничего нет связанного с NAND и MTD.
Интернет подсказывает что все начинается с определения NAND. Должна быть строчка:

Код

NAND device: Manufacturer ID: .....

Но у меня ее нет.
Вопросы собственно в следующем:
1) Правильно ли я полагаю что для данной микросхемы NAND не нужно писать драйвера, а должен подхватится из nand_base.c (в nand_ids.c есть строка с моим chip ID и прочими атрибутами)
2) Навтыкал в nand_base.c свои чекпоинты printk, но они нигде в консоли не отображаются. хотя при сборке ядра nand_base.o генерится и собирается. На каком этапе связки bootargs (параметр mtdparts) и загрузки ядра и что может быть упущено?
Я так понимаю что связка с драйвером идет по имени, переданном в bootargs? В данном случае это имя "nand"?

[xor.kruger]

Выложите для начала лог загрузки и прикрепите конфиг ядра.

[yurmala]

Сам уже разобрался...)) и написал драйвер. Что не может не радовать.
Да, действительно нужно написать свой драйвер для доступа к памяти NAND
За основу взять один из простейших в drivers/mtd/nand
А уже nand_base.c и nand_ids.c подцепятся из этого написанного драйвера.
вопрос закрыт.

[yurmala]

ucLinux + NAND Flash
Доступ реализован через MTD
Есть задача, в одной из партиций реализовать циклический архив неких событий.
Тут сразу встал вопрос - как бы не убить флэш быстро.
Самое примитивное решение - доступ к /dev/mtdblock3 как к RAW области. Размер партиции - порядка 120 мб. Одна запись архива 30-50 байт, поэтому при записи в цикле убьется флэш не сильно быстро.
Возник вопрос - а есть ли решение с файловой системой?
Вот например JFFS2. Монтирование с ключом noatime. Этого не достаточно? Правильно ли я понимаю, что время перезаписи файла будет все равно меняться (в одной ячейке флэша) при каждом добавлении записи в архив?
При монтировании на NAND фс JFFS2 система говорит что мол найдена таблица плохих блоков и прочее...Если вдруг со временем какой-то блок превысит количество циклов перезаписи, этот блок пометится как "плохой" сам? Или чудес не бывает? )))
Или JFFS2 в любом случае плохой вариант априори, т.к. она журналируемая и пофиг на разного рода ключики?
Какие еще варианты с ФС? ext2?
Есть ли решение с файловой системой, при котором при записи в файл не будет меняться дата изменения/доступа файла?

[Dron_Gus]

Почитайте про UBI/UBIFS.