Lampus

Не поместится, у него минимальный футпринт не такой уж и маленький (ЕМНИП, судя по древним спискам рассылки около 700 кБ). Но никто, по идее, не запрещает поставить внешнюю DataFlash с образом ядра и initrd, а во внутреннюю флеш запихнуть загрузчик. Да и вообще, Linux на железке без MMU - не очень весело. Вот та древняя информация: http://blackfin.uclinux.org/gf/project/bla...cker_item_id=75 Думаю что для современных версий ядра оно будет занимать ещё больше. Друго источник говорит о минимальном размере в 512 кБ: http://comments.gmane.org/gmane.linux.uclinux.devel/11747

Если кому интересно, можете почитать мои старые статьи на эту тему: http://habrahabr.ru/blogs/linux/123145/ http://habrahabr.ru/blogs/linux/123266/ Может содержать некоторые ошибки, ибо когда писал, только начинал вникать в эту тему, но в целом понимание основных структур давать должно. Что касается прриведённого там примера драйвера, то там для "полного счастья" следует все совместно используемые данные выносить в структуру с общей блокировкой.

Во-первых, скорее всего имеется в виду /dev/spidevB.X, где B - номер шины, X - номер Chip-Select'а. Если требуетсмя half-duplex обмен данными, то тупо read()/write() из файла устройства. Если нужен full-duplex обмен данными, то это придётся делать через соответсвующий ioctl(). Ссылки на примеры выше уже привели. Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

Есть такая штука как spidev. Как правило инициализируется в файле борды, для него указывается номер шины SPI и номер CS. После чего после загрузки образуются файлы вида /dev/spidevB.C, где B - номер шины, C - номер ChipSelect'а. А дальше открываешь его как файл и что надо читаешь/пишешь. Если же речь идёт о драйвере для какой-то определённой железяки висящей на SPI-шине, то надо смотреть в сторону /sys/class/spi*/... Рекомендую изучить документацию идущую с ядром в папке Documentation/spi

Надо посмотреть есть ли в образе rootfs файл /dev/console Смахивает на то что NAND-флеш повреждена. Здесь видно как отрабатывает ECC. У тебя случаем к ядру ничего не прицеплено в качестве initramfs? grep CONFIG_INITRAMFS_SOURCE .config Вообще смущает то, что всё это начинает валится после запуска udev. Покажи-ка вывод: grep CONFIG_MTD .config

0. Не знаю, но возможно всё =) 1. Linux, запихан и портирован во всё что можно. А для того что нельзя модифицировали и туда тоже запихали. Ну это для "крупняка", если что помельче, то какой-нибудь ecos или FreeRTOS. 2. У StarterKit цены весьма демократичные, так что можно сразу и Kit купить. 3. Разобраться с Си таки придётся, ибо на нём писаны почти все RTOS-ы и ядро Linux. Но чистый Си гораздо проще всех этих высокоуровневых C++ и Java.

Во-первых, avrdude под Linux есть нативный. GUI в линуксе для него при желании тоже можно откопать. Во-вторых, описание запуска AvrStdudio есть тут http://easyelectronics.ru/avr-studio-v-linux.html Ради каких целей используется древний PCAD 4.5? Можно попробовать Eagle для схем/pcb и ng-spice для моделирования, ну это если есть желание.

Ничего лучше чем ковырять исходники ядра Linux тут предложить просто нельзя.

Ды библиотеки эти как раз таки есть, а вот полинкованы они на очень старую версию glibcxx. Копать в сторону настройки переменной окружения LD_LIBRARY_PATH и поиска нужной версии glibcxx. Посмотреть какие версии поддерживает ваша плюсовая либа можно командой strings /usr/lib/libstdc++.so.*|grep GLIBCXX Ну или в /lib, а не /usr/lib. Лежит она где как.