У Вас, судя по всему, ЖКИ замаплен на IO, отсюда и

Код

CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y

у меня же буфер передачи сидит в системной памяти, и я использую

Код

CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT =y

Впрочем, я пробовал оба варианта...

Код

# ls /sys/class/graphics/
fb0 fbcon

Нарисуйте однобитную картинку и выведите ее на экран через /dev/fb0 - если отображается правильно - никаких проблем с консолью быть не должно, если неправильно - смотрите на команды своего ЖКИ, возможно там ошиблись. Можно через mmap вывести что-нибуть осмысленное (там экран просто массивом будет представлен) - тогда сразу ясно все будет.
можете в качестве примера взять
http://sasamy.narod.ru/rgbtest.c
только учитывая свои реалии - один бит на пиксель и разрешение 132х32, т.е. вместо моего цикла с заливкой придумайте что-то свое - остальное как шаблон можно один в один.

Цитата

Нарисуйте однобитную картинку и выведите ее на экран через /dev/fb0 - если отображается правильно - никаких проблем с консолью быть не должно, если неправильно - смотрите на команды своего ЖКИ, возможно там ошиблись. Можно через mmap вывести что-нибуть осмысленное (там экран просто массивом будет представлен) - тогда сразу ясно все будет.

echo '1' > /dev/fb0 рисует биты, соответствующие ascii коду символа "1", то есть команды на ЖКИ проходят нормально. Проблема с заполнением fbcon'ом буфера на передачу, info->screen_base который в Вашем драйвере...

Исходя из поставленной задачи (просто выводить некий текст на ЖКИ, это будет делать одно приложение), я подумал, что фреймбуфер в данном случае, как и все Линуксовые механизмы, не нужны, проще прямо в /dev/spi писать из проги, что нужно. буду реализовывать этот вариант.

fbcon работает через read/write ф-ции драйвера - они стандартные из ядра, сомневаюсь что там ошибки есть. То что 8 бит без ошибки заполняет - это вообще ни о чем не говорит - заполните весь экран осмысленным содержимым.

Например на какие я грабли наступал - PDC может не иметь доступа к памяти в нужное время и получаем ошибку опустошения буфера, драйвер сбрасывает ошибку и повторно отсылает сообщение - для него все логично а для экрана который ожидает данные после команды - совсем нет потому что он начало сообщения принимает за продолжение прерванного или наоборот после сброса CS ждет команду а ему прилетают данные и все "разъезжается". У вас в драйвере SPI непрерывно "молотит" нагружая шину, я делал небольшие передышки - нет никакого смысла от обновления напримр 200 раз в секунду - достаточно 10-15 на таких мелких экранах.

Цитата

fbcon работает через read/write ф-ции драйвера - они стандартные из ядра, сомневаюсь что там ошибки есть. То что 8 бит без ошибки заполняет - это вообще ни о чем не говорит - заполните весь экран осмысленным содержимым.

Заполнил, все ок. Я специально вывел на экран адрес info->screen_base и адрес, по которому пишет ф-ция fbcon_putcs(). Они разные.

Для скролинга экрана еще используются COPYAREA или IMAGEBLIT - я не помню точно, там он по своему алгоритму в зависимости от установленных флагов акселерации этих операций и возможности изменения панорамы (перемещение видимого окна внутри виртуального буфера) выбирает ф-цию - в вашем случае нет аппаратного ускорения этих операций
.accel = FB_ACCEL_NONE,
и панорамы тоже нет

.xres_virtual = X_RES,
.yres_virtual = Y_RES,

.xpanstep = 0,
.ypanstep = 0,
.ywrapstep = 0,

по-моему COPYAREA используется.