On Thu, 12 Jan 2023 at 18:08, Norman Feske <norman.fe...@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__restacked > [2] > https://github.com/genodelabs/genode/blob/master/repos/os/include/platform_session/dma_buffer.h > 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 _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users