sasamy

Имхо - это из-за кривого драйвера atmel_spi, лучше не использовать для записи cp, вместо этого попробовать flashcp из состава mtd-utils. #flashcp -v /home/image.jffs2 /dev/mtd0

Не видится dataflash потому что я забыл сказать что нужно отключить в ядре MMC_AT91 или поправить файл board-sam9260ek.c на предмет таблицы spi-устройств, например у меня так /* * SPI devices. */ static struct spi_board_info ek_spi_devices[] = { { /* DataFlash chip */ .modalias = "mtd_dataflash", .chip_select = 0, .max_speed_hz = 15 * 1000 * 1000, .bus_num = 0, }, }; потому что в ядреном варианте есть такой момент /* * SPI devices. */ static struct spi_board_info ek_spi_devices[] = { #if !defined(CONFIG_MMC_AT91) ..... и наша dataflash в таблицу spi-устройств не попадает. Почему в "стандартном" ваарианте mmc и dataflash взаимоисключающие устройства я не знаю, после правки ничего подозрительного не наблюдал. Кпроме этого вы все же проигнорировали мои предупреждения:) 1 Размер блока в dataflash 1056 байт - размер раздела должен быть кратен ему, иначе он будет доступен только в режиме чтения (0x100000 не делится нацело на 0x420) 2 Вместо блочного устройства при копировании cp /home/img.jffs2 /dev/mtdblock0 нужно использовать символьное устройство /dev/mtd0, то что у вас прошло копирование без ошибок говорит лишь о том что реально раздел не существует и создание файла устройств через mknod ничего не решает и при копировании он был замещен файлом img.jffs2. PS Не уверен все же что нужно делать размер раздела кратным 1056 байт, возможно достаточно кратным я делал кратным 1056, что автоматически означает и кратность 528, так что если это критично - можно попробовать.

Кстати - с чего вы взяли что прерывания должны срабатывать 20 раз в секунду ? Насколько я понял прерывание срабатывает по внешнему событию а потом через 1/20 секунды заускается отложенное действие (по сути отложенная обработка прерывания), после чего прерывания от ts снова разрешены.

А чем не устраивают обычные таймеры в ядре ? Имхо намного проще и главное - работают :) Например #define REFR_TIME (HZ / 20) struct timer_list timer; static void my_timer(unsigned long param) { struct my_param *par = (struct my_param *)param; /* делаем свои дела */ /* заряжаем таймер на следующий период */ mod_timer(&timer, jiffies + REFR_TIME); } /* где-то в ф-ции инициализации */ init_timer(&timer); timer.data = (unsigned long)param; timer.function = my_timer; timer.expires = jiffies + REFR_TIME; add_timer(&timer);

Если что - после соединения информацию про интерфейс можно брать из /proc/net/dev. Например:

1) Указать в опциях pppd ключ updetach 2) не совсем понял что нужно 3) завершаю killall pppd - вроде не замечал никаких глюков с последующим запуском.

Если разработка на уровне ядра - можно выделить некэшируемый буфер (dma_alloc_coherent) и сообщить драйверу spi что буфер уже смапен (is_dma_mapped).

По ссылке все пункты - 1,2,3,4 выполняются за один раз - make :) А вообще Не совсем понятно как у вас собирается еще и newlib за один make. Понятно если до трех шагов сократить - без последнего 4, но я так не пробовал потому что всегда пользуюсь готовыми скриптами для сборки - сильно экономит время и нервы :)

# pwd /home/sasa/sam9work/linux-2.6.30.4 # grep "*" -m 14 drivers/mtd/cmdlinepart.c /* * Read flash partition table from command line * * Copyright 2002 SYSGO Real-Time Solutions GmbH * * The format for the command line is as follows: * * mtdparts=<mtddef>[;<mtddef] * <mtddef> := <mtd-id>:<partdef>[,<partdef>] * where <mtd-id> is the name from the "cat /proc/mtd" command * <partdef> := <size>[@offset][<name>][ro][lk] * <mtd-id> := unique name used in mapping driver/device (mtd->name) * <size> := standard linux memsize OR "-" to denote all remaining space * <name> := '(' NAME ')' что касается параметров ядра в конфиге # grep "MTD" .config | grep -v "is not set" CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # Self-contained MTD device drivers CONFIG_MTD_DATAFLASH=y CONFIG_MTD_DATAFLASH_WRITE_VERIFY=y # grep "JFFS2" .config | grep -v "is not set" CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_WRITEBUFFER=y CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_RTIME=y Для примера # grep "CONFIG_CMDLINE" .config CONFIG_CMDLINE="mem=32M rootwait root=/dev/mmcblk0p1 mtdparts=spi0.0-AT45DB321x:0x10800@0x40f800(log)" это означает что я хочу увидеть раздел в 64 кб (0х10800 / 0x420 = 0x40 = 64 - обращаю внимание - блоки в dataflash 1056 = 0x420 байт) в самом конце моей dataflash 0x420000 - 0x10800 = 0x40f800, все что до этого адреса меня не интересует - там например uboot и ядро. Корневая фс у меня на sd карте - мне так удобней :) Грузимся U-Boot> tftpboot 21000000 zlinux macb0: link up, 100Mbps full-duplex (lpa: 0xffff) Using macb0 device TFTP from server 192.168.0.2; our IP address is 192.168.0.136 Filename 'zlinux'. Load address: 0x21000000 Loading: ################################################################# ############################## done Bytes transferred = 1382892 (1519ec hex) U-Boot> bootm 21000000 ## Booting kernel from Legacy Image at 21000000 ... Image Name: linux-2.6 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1382828 Bytes = 1.3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... .... дальше не все интересно - буду писать только то на что обратить внимание Kernel command line: mem=32M rootwait root=/dev/mmcblk0p1 mtdparts=spi0.0-AT45DB321x:0x10800@0x40f800(log) отлично - командная строка на месте - никто ее не поменял (например uboot) atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12) mtd_dataflash spi0.0: AT45DB321x (4224 KBytes) pagesize 528 bytes (OTP) 1 cmdlinepart partitions found on MTD device spi0.0-AT45DB321x Creating 1 MTD partitions on "spi0.0-AT45DB321x": 0x00000040f800-0x000000420000 : "log" вот и наш раздел. Логинимся, смотрим где наш раздел в устройсвах # ls -l /dev | grep mtd crw-rw---- 1 root root 90, 0 Dec 31 17:00 mtd0 crw-rw---- 1 root root 90, 1 Dec 31 17:00 mtd0ro brw-rw---- 1 root root 31, 0 Dec 31 17:00 mtdblock0 На месте, у меня файлы устройств создаются автоматом потому что использую mdev из состава busybox. Создались два char device - один rw другой ro и блочное устройство. Создаем пустую фс # ls -l /tmp # # echo "sasa" > /tmp/sasa # ls -l /tmp -rw-r--r-- 1 root root 5 Dec 31 17:01 sasa # mkfs.jffs2 -d /tmp -l -p -e 0x2100 -v -n -o /root/img.jffs2 / f 0644 5 ( 73) 0:0 sasa Compression mode: priority Compressors: none compr: 1 blocks (5) decompr: 0 blocks lzo (prio:80) - compr: 0 blocks (0/0) decompr: 0 blocks zlib (prio:60) + compr: 0 blocks (0/0) decompr: 0 blocks rtime (prio:50) + compr: 0 blocks (0/0) decompr: 0 blocks Compression errors: 0 # cp /root/img.jffs2 /dev/mtd0 # # ls -l /mnt # mount -t jffs2 /dev/mtdblock0 /mnt JFFS2 write-buffering enabled buffer (528) erasesize (8448) # ls -l /mnt -rw-r--r-- 1 root root 5 Dec 31 17:04 sasa # cat /mnt/sasa sasa # echo "pasa" > /mnt/pasa # ls -l /mnt -rw-r--r-- 1 root root 5 Dec 31 17:07 pasa -rw-r--r-- 1 root root 5 Dec 31 17:04 sasa # umount /mnt # mount -t jffs2 /dev/mtdblock0 /mnt JFFS2 write-buffering enabled buffer (528) erasesize (8448) Empty flash at 0x00000078 ends at 0x00000210 # ls -l /mnt -rw-r--r-- 1 root root 5 Dec 31 17:07 pasa -rw-r--r-- 1 root root 5 Dec 31 17:04 sasa # # df -h Filesystem Size Used Available Use% Mounted on /dev/root 3.7G 311.4M 3.2G 9% / mdev 14.5M 0 14.5M 0% /dev /dev/mtdblock0 64.0K 24.0K 40.0K 38% /mnt В какой из загрузочных скриптов добавить mount -t jffs2 /dev/mtdblock0 /mnt думаю сами разберетесь :)

Нужно указать геометрию разделов ядру и работать как с обычными дисками. Самое простое - через параметры загрузки ядру указать, у меня например так mtdparts=spi0.0-AT45DB321x:0x1080(mbs),-(kernel). Это кстати давно обсуждалось на форуме где все молчат :) и если использовать в качестве корневой фс раздел то нужно блочное устройство и указывать и тип фс, например root=/dev/mtdblock1 rootfstype=jffs2 если для логов использовать - то можно просто подмонтировать нужный раздел в нужную директорию, еще сейчас многие используют различные варианты unionfs которая позволяет сделать прозрачной запись на две фс одна из которых в ro а друга в rw смонтирована.

http://tuxotronic.org/wiki/tutorial/arm7-build-toolchain

мне кажется вложенность прерываний в совокупности с приоритетами как минимум полезна для rtos, а если программист не использует аппаратные возможности платформы и изобретает софтовый велосипед причем медленный, это и есть проявление непрофессионализма.

Контора в которой я сейчас работаю сама ничего не производит и разработкой не занимается. Ссылку привел потому что я не могу похвастаться разработками под коммерческие ОС на чем настаивал оппонент :) Насчет доходности контор - используем мы в своих проектах устройства на qnx, только от этого не холодно не жарко. Реалтайм там вообще нафик не нужен, стоят они немеряно но заказчики выбирают их, хотя есть альтернативы, потому что пропиарены они хорошо, заказчики вообще не знают в большинстве своем что такое ОС :) Конторы в которых все держится на одном человеке работающем на полставки на любой ОС не выживут.

http://qnx.org.ru/forum/index.php?topic=48...g44750#msg44750 Или в Германии не умеют считать деньги ?

Зачетный бред :)

После сообщения "Entering KGDB" нужно закрывать сессию в миникоме (перед запуском gdb) или как вариант использовать различные порты для консоли и для gdb.

Я не специалист в этом, по stty как и практически любой команде в linux можно смотереть man #man stty короткую подсказку можно и так #stty --help Последовательные порты/терминалы такие же древние как и сами ос, так что информации море, правда в основном на английском. Что-то советовать не могу, потому что не занимаюсь этим. Имхо поиск можно начать тут http://tldp.org/HOWTO/Serial-HOWTO.html кое-что есть на русском - при наличии интернета найдете быстро.

Судя по выхлопу вашего stty -a - это не raw режим и потом что значит не работает echo ? 1 В первом терминале #stty -F /dev/ttyUSB0 raw -echo #cat /dev/ttyUSB0 2 Во втором терминале #echo "hello world" > /dev/ttyUSB0 смотрим что вылезло в первом. в вашем случае проблема в том что включено локальное echo (то что добавлено -echo в stty его отключает). во время этих действий не должны работать другие программы с этим портом иначе они могут переопределить настройки так как будут для него управляющим терминалом. PS если по каким то неизвестным причинам echo все же не работает (хотя с чего бы это :) можно и так как вы раньше делали через cat

Чем пишите/читаете - какая-то своя программа или стандартные утилиты типа echo/cat ? Поспешные выводы. Обычно в ванильном ядре драйверы все же работают немнога :) Для начала попробуйте настроить raw режим например так #stty -F /dev/ttyUSB0 raw потом пробуйте писать/читать. текущее состояние можно посмотреть например так #stty -F /dev/ttyUSB0 -a

ядро 2.6.29.2 menuconfig ---> Power management options ---> Power Management support ----> Suspend to RAM and standby честно говоря никогда не пользовался этим - я не знаю на какие события он просыпаться умеет, думаю при желании можно что-нибуть придумать.

linux 2.6.29 с dataflash до строки приветсвия грузится секунд 5 не больше, загрузчик свой - переделанный из atmel bootstrap, можно еще быстрей загрузить - не было такой цели, думаю 3 секунды вполне достижимый результат, у меня в драйвере lcd большие задержки + корнеавя фс на sdhc которая сама по себе требует времени для обнаружения и инициализации. rootfs на initramfs думаю сократит время существенно.

Работает, по крайней мере у меня на sam9260, правда я не пробовал sysrq-g - не было надобности, я только через kgdbwait прерывал загрузку ядра, ставил брэкпоинт и отлаживал - мне нужно было посмотреть как probe в моем драйвере отрабатывает, еще как на атмеловском драйвере глюк выростает при передаче буфера больше 4 кб если ему не назначить явно буфер для приема. Можете патч отправить - мне и без него несложно 5 строк дописать :)

для некоторых систем 100-200 кб ram лишними не бывают... инициализацией скорей всего занимается сама bios которая предоставляет интерфейс acpi, но это имхо, я не разбирался с этим, есть еще разные программы в linux котрые якобы следят за правильным засыпанием/восстановлением системы но имхо они всего лишь пытаются правильно восстановить работу демонов в userspace. Кстати - заново выполнить код инициализации в подавляющем большинстве случаев не получится - там выпоняются такие действия как резервирование irq, выделение памяти под буферы и кеши и тд и тп котрые при повторе просто завалят систему, так что имхо это вообще фантастика для систем не имеющих bios и acpi как в x86.

проблемы Analog Devices - это проблемы Analog Devices, речь шла о том что на rm9200 читать sd быстро не получится но вообще быстрое чтение с внешнего носителя - не вопрос. При чем тут вообще xip - не путайте теплое с мягким, речь шла об аналоге hibernate в windows, он кстати вполне себе живет в linux на х86 - suspend to disk называется, используя acpi, так вот проблема в том что после восстановления образа ram с нешнего носителя нужно заново инициализировать периферию так как питание было полностью отключено, но в ram кода инициализации уже нет, так как ядро при загрузке освободилось от него.

не вопрос - можно получить хорошие скорости, я просто конкретно про rm9200 ситуацию уточнил Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно :) Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.