LINUX.ORG.RU

uclinux не работает mmap

 


0

1

Пытаюсь запустить nano-X GUI на uclinux. Не запускается из за того, что mmap на /dev/fb0 возвращает No such device.

Сам фреймбуфер находится в памяти микроконтроллера и определяется через Device tree. Драйвер используется simplefb.

Если следать cat /dev/urandom > /dev/fb0 экран заполняется шумом, т.е. вроде как драйвер нормально работает.

В самом драйвере, по умолчанию, нет функции fb_mmap, пытался прикрутить свою, в ней просто писал printk(«Hello»), на экране ничего не появилось, такое ощущение что mmap и не пытается вызвать эту функцию из драйвера.

В нете читал что mmap на системах без MMU не работает с блочными устройствами.

Фреймбуффер к блочным относится?

Какие есть варианты получить доступ к фреймбуфферу из приложения?

Притом что адрес известен, но при попытке записи по этому адресу из приложения, ядро падает с исключением Mem manage fault, если же писать туда что-либо из драйвера - все нормально пишется, это я проверял через ioctl, т.е. в драйвере просто делал заливку экрана одним цветом, а из приложения вызывал ioctl и экран заливался нужным цветом.

Вариант через open/lseek/write работает, но ну его нафиг.


Фреймбуффер к блочным относится?

″ls -l″ что показывает? К символьным (char).

″cat > /dev/fb0″ работает через write().

mky ★★★★★
()
Ответ на: комментарий от rexton

(#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE

In the MMU case: As for ordinary regular files.

In the no-MMU case: The character device driver may choose to honour the mmap() by providing direct access to the underlying device if it provides memory or quasi-memory that can be accessed directly. Examples of such are frame buffers and flash devices. If the driver does not provide any such support, then the mapping request will be denied.

Ну, написано, что в случае no-MMU оно может работать, если драйвер позволяет. А если дравер не поддерживат, то работать не будет. ИМХО, вам нужно поискать fb драйвер, который на no-MMU умеет mmap, чтобы понять, как именно это делается.

Здесь https://uclinux-dev.uclinux.narkive.com/qD7mUzXH/m68k-trying-accessing-fb-memory пишут, что не нужно в драйвере делать fb_mmap(), нужно определить HAVE_ARCH_FB_UNMAPPED_AREA и реализовать get_fb_unmapped_area(). Отправляют смотреть код для Blackfin. Дальше там пишут, что можно пробовать делать mmap для /dev/mem, чтобы получить нужные адреса, но есть вариант, что сам экран использует свою отдельную память, драйвер при write()/read() может заставлять экран перечитать из памяти МК. В этом случае mmap памяти для программы бесполезен...

Вы делали заливку через модификацию и вызов ioctl() дравера экрана или заливка работает из любого драйвера?

mky ★★★★★
()
Ответ на: комментарий от mky

нужно определить HAVE_ARCH_FB_UNMAPPED_AREA и реализовать get_fb_unmapped_area()

либо воспользоваться обобщенной реализацией:

select FB_PROVIDE_GET_FB_UNMAPPED_AREA

anonymous
()
Ответ на: комментарий от mky

Заливку делал из драйвера экрана.

Попробовал собрать ядро с HAVE_ARCH_FB_UNMAPPED_AREA, а get_fb_unmapped_area() в драйвере не делал, потому что в fbmem.c уже есть реализация.

Выхлоп mmap не поменялся, no such device.

По поводу mmap /dev/mem, если я правильно понял, то все равно надо реализовывать ioctl который будет обновлять экран по какому либо событию, тогда это не имеет смысла… Можно или простым write всю область экрана обновить (по завершению отрисовки), ну или попробовать DMA прикрутить, например выделить память под буфер, nano-X пусть в эту память рисует, а DMA уже кидает в реальный фреймбуфер.

Короче пока что получаются одни грабли.

rexton
() автор топика
Ответ на: комментарий от anonymous

С DRM еще не разбирался никак.

Потому вопрос, он можем дать доступ к физическому адресу фреймбуффера? (в камне есть контроллер RGB дисплея который настроен на адрес 0x20000000, именно с этого адреса на экран данные и выводятся, и именно к этому адресу привязан framebuffer).

Или подразумевается, что использовать функционал DRM для рисования на экране? если так, то нужно писать драйвер для nano-X который сможет работать с DRM, тоже так себе вариант.

rexton
() автор топика
Ответ на: комментарий от rexton

если я правильно понял, то все равно надо реализовывать ioctl который будет обновлять экран по какому либо событию

Не совсем. Это зависит от конкретного экрана. Одни сами всё время читают память, других нужно «пинать» через ioctl. Если сделать заливку не из дравера экрана, можно будет понять, какой у вас экран. И во втором случае пытаться прикрутить DMA смысла нет.

mky ★★★★★
()
Ответ на: комментарий от anonymous

Спасибо за наводку! Проверю чуток позже, сейчас плату новую жду под этот камень, как придет - проверю и отпишусь.

rexton
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.