video and usb driver (rk3588)

[Michael Grunditz]

On Thu, 12 Jan 2023 at 18:08, Norman Feske <norman.feske at 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