On Thu, 12 Jan 2023 at 18:08, Norman Feske norman.feske@genode-labs.com wrote:
Hi Michael,
Hi , and thanks a lot for answer.
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.
Sorry it is just a name that managed to creep into my drivers.config. Could be any name. The component gui_fb is not part of the build.
A modern framebuffer driver should be a mere client of the 'Capture' service provided by the nitpicker GUI server.
I am using the "boot" driver.
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__restacke... [2] https://github.com/genodelabs/genode/blob/master/repos/os/include/platform_s...
Will try this after every other option :-) I doubt it will solve alignment fault.
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.
Well ,shouldn't be a problem.
The symptom reminds me of [3] (allowing unaligned memory accesses in user space), but why would that configuration be ineffective in your case?
I doubt that it is related. The "A" bit is set to '0'.
Maybe the fault IP refers to some special (neon?) instruction with tighter constraints? Have you had a look at the faulting instruction?
Sorry , for being uneducated, but is "ip" an instruction (doesn't make sense , isn't an opcode) or is it an address? If address, where can I look it up?
Thanks , again. USB is currently a mess. I started from older imx8 driver which depends on u-boot to start. I use u-boot "usb start" before boot. But it works :-)
Michael