video and usb driver (rk3588)

Norman Feske norman.feske at genode-labs.com
Thu Jan 12 18:08:02 CET 2023


Hi Michael,

>> Kernel: MMU-fault not handled ESR=0x92000061
>> Kernel: init -> drivers -> gui_fb -> ep raised unhandled MMU fault
>> ip=0x1009bb4 fault-addr=0x113d76ac type=unknown
>>
>> But as you can see , if I move the mouse pointer I get that ESR after
>> the pointer moves a small amount of pixels. and graphics stops.

I am bit confused by the role of the gui_fb component in your scenario. 
Since we introduced the 'Capture' session in 20.08 [1], this component 
(and more generally the 'Framebuffer' session interface) should no 
longer be needed for most GUI scenarios. Only in scenarios where 
nitpicker is used in a nested way (Sculpt's Leitzentrale, demo.run), the 
gui_fb component serves a purpose nowadays.

A modern framebuffer driver should be a mere client of the 'Capture' 
service provided by the nitpicker GUI server.

BTW, the official way to obtain a contiguous RAM buffer (for the use as 
framebuffer) is platform driver. For a 'Dma_buffer' object, you can 
request the 'dma_addr' [2] to be poked into the graphics device register 
for the framebuffer base address.

[1] 
https://genode.org/documentation/release-notes/20.08#The_GUI_stack__restacked
[2] 
https://github.com/genodelabs/genode/blob/master/repos/os/include/platform_session/dma_buffer.h

> Some more info. The crash is in the copy to fb ...
> _captured_screen.apply_to_surface(surface);
> It fails right away when moving the mouse. I have checked the size and
> it is always the same and the fault address is half way in (~ about
> where the mouse pointer is). I don't understand. The driver samples
> from screen and writes to fb. It is done with a timer , so I can't see
> how it  can be affected by changes in screen.
> Another thing is that it might get interrupted by the usb interrupt,
> but it seems quite unlikely. ESR is still unaligned write. I can
> provoke it directly with a odd size.

Generally speaking, while blitting 32-bit pixels, pixels may be 
read/written at 32-bit boundaries. When moving the mouse cursor to an 
uneven position, the 16x16 pixels of the mouse cursor are copied from/to 
a 32-bit aligned (not 64-bit aligned) position.

The symptom reminds me of [3] (allowing unaligned memory accesses in 
user space), but why would that configuration be ineffective in your 
case? Maybe the fault IP refers to some special (neon?) instruction with 
tighter constraints? Have you had a look at the faulting instruction?

[3] https://github.com/genodelabs/genode/issues/3370

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth




More information about the users mailing list