yurmala

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

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

Приветствую! Отладочная плата 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"?

Есть u-boot запускающийся из чиповой RAM памяти размером 64KB также есть внешняя DRAM память размером 32MB u-boot загружается и корректно инициализирует эту внешнюю память. Возникла необходимость добавить в u-boot поддержку загрузки ядра с SD карты. Для этого был найден драйвер MMC. mmc init успешно инициализирует SD карту. Теперь нужно подключить файловую систему FAT, для использования команды fatload... В u-boot включаю опцию CONFIG_CMD_FAT. И тут полезли проблемы ))) модуль fat.c имеет 3 глобальных массива по 64KB каждый. загрузчик u-boot.lds пытается загрузить из в .bss регион встроенной RAM памяти. И естественно, это у него не получается - ибо ее размер 64KB /home/user/projects/..../arm-uclinuxeabi-ld.real: u-boot section `.bss' will not fit in region `RAM' /home/user/projects/..../arm-uclinuxeabi-ld.real: region `RAM' overflowed by 186932 bytes make: *** [u-boot] Error 1 И тут у меня возникает ступор. Что делать в такой ситуации? 1) Задал в u-boot.lds скрипте адрес для RAM памяти как адрес внешней RAM (с ее размером), u-boot скомпилировался но естественно не запустился, т.к. внешнюю RAM нужно вначале проинициализировать, а уже потом использовать. Тупик. 2) Создал в u-boot.lds отдельный регион DRAM со своим адресом и размером. в модуле FAT.c для этих массивов указал директиву хранения в секции DRAM u-boot собрался но u-boot.bin стал размером более 2Гб. Т.е. LD скрипт все это запихнул в прошивку (смещение до начала DRAM и сами нулевые массивы). Вообщем опять тупик. Так как быть?

И еще кстати один вопрос связанный с компилированием простейшего example кода для демонстрации одного pthread потока (из учебника Getting_started_with_uClinux_A.pdf). Сам пример: #include <stdio.h> #include <pthread.h> static void* mythread(void* arg) { printf("mythread called arg = %s\n", (char *)arg); return NULL; } int main(int argc, char* argv[]) { int ret; pthread_t thread1; pthread_t thread2; if (argc < 3) {. printf("Usage: pthreads arg1 arg2\n"); exit(1); } ret = pthread_create(&thread1, NULL, mythread, argv[1]); if (ret != 0) { printf("Failed to create thread 1 ret=%d\n", ret); exit(1); } ret = pthread_create(&thread2, NULL, mythread, argv[2]); if (ret != 0) { printf("Failed to create thread 2 ret=%d\n", ret); exit(1); } pthread_join( thread1, NULL); pthread_join( thread2, NULL); return 0; } Вот makefile для него CFLAGS= -Wall -W LDFLAGS= -Wl -elf2flt -lpthread CC= /usr/local/bin/arm-elf-gcc RM=rm -f PROG=thread SRC= thread.c OBJ=$(SRC:%.c=%.o) $(PROG): $(OBJ) $(CC) $(CFLAGS) -o $(PROG) $(OBJ) $(LDFLAGS) .PHONY: clean all dep clean: $(RM) $(PROG) $(OBJ) *~ *.gdb .depend *.elf2flt *.elf Скомпилированное приложение получается размером 116 кб. Ну это же неимоверно много? Почему так? p.s. Для сборки использую тулчейн установленный из arm-elf-tools-20040427.sh (опять же по рекомендации из этого учебника...)

Написал приложение для запуска в ucLinux на демо плате EA LPC2478. В документе Getting_started_with_uClinux_A.pdf идущем вместе с платой есть примеры сборки приложений... там ссылаются на следующие параметры компиляции/сборки CFLAGS = -Wall -W LDFLAGS = -Wl, -elf2flt -lpthread CC = /usr/local/bin/arm-elf-gcc Так и сделал - исполняемый файл в FLT формате собрал. Стал смотреть в интернете на форумах - везде ссылаются на: CFLAGS = -Wall -Os -DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -fomit-frame-pointer -fno-common -fno-builtin LDFLAGS = -Wl, -elf2flt="-r" -lpthread CC = /home/user/uClinux-dist/tools/ucfront-gcc /usr/local/bin/arm-elf-gcc Попробовал. Тоже получилось собрать исполняемый FLT файл. Так как все-таки правильно? Или оба варианта рабочие? Просто пока под рукой нет TARGET чтобы проверить...

в моем понимание вначале кварц а уже потом программа. т.е. без кварца программа не запустится. А не наоборот. разве нет?

уверены что программа именно не запускается? т.е. управление по 0 адресу не происходит? схемотехника подключения JTAG типовая?

да, я через TortoiseHG пока и работаю. Но действительно, милее встроенные варианты тулсов :rolleyes:

SyncLair, я уже разобрался. Потому и дал полезную информацию для остальных, на будущее. Внимательно нужно быть с передаваемым буфером. Он должен находится в USB RAM. Поэтому функция disk_write у меня стала выглядить так: DRESULT disk_write(BYTE drv, /* Physical drive number (0..) */ const BYTE *buff, /* Data to be written */ DWORD sector, /* Sector address (LBA) */ BYTE count /* Number of sectors to write (1..255) */ ) { if (usb_status & STA_NOINIT) return RES_NOTRDY; memcpy((void*)UserBuffer, buff, MS_BlkSize * count); if ( MS_BulkSend( sector, count, UserBuffer) == OK ) return RES_OK; else return RES_ERROR; }

Давненько используем GPRS терминал Cinterion MC52i. Достаточно надежный TCP/IP стэк. Сильно облегчил разработку проекта. Удобен для стартапа, где важнее вопрос "что и когда передать", чем "как передать". Имхо.

Кстати, тоже столкнулся с с этой директивой. Давненько уже отписался разрабам Keil. Но как-то они последние месяцы компилятором не шибко заняты.

TigerSHARC, так вы ищите run-time решение разбора PCM или действительно устраивает переконвертирование сбоку?

В коллекцию исходников: Open Source утилитка расчета всевозможных контрольных сумм в основном табличным методом. http://fsumfe.sourceforge.net/ Сами алгоритмы лежат в папке src\fsumfe\digest\algo\

Тут еще зависит от конкретного компилятора (возможности оптимизатора). Действительно, ASM-листинги в помощь. Хотя бы для типовых операций.