Re: video and usb driver (rk3588)
On Thu, 12 Jan 2023 at 21:32, Michael Grunditz wrote: > > Update! > > It is the surface clipping that generates the fault (as expected) > commenting that out makes things work. > I guess it is slower without clipping. The movie: https://twitter.com/QtARM/status/1613638001573396480 ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
Update! It is the surface clipping that generates the fault (as expected) commenting that out makes things work. I guess it is slower without clipping. ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
On Thu, 12 Jan 2023 at 18:08, Norman Feske wrote: > > Hi Michael, > Hi , and thanks a lot for answer. > >> Kernel: MMU-fault not handled ESR=0x9261 > >> 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
Re: video and usb driver (rk3588)
Hi Michael, Kernel: MMU-fault not handled ESR=0x9261 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 ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
On Thu, 12 Jan 2023 at 03:19, Michael Grunditz wrote: > > Hello! > > I have USB working: > [init -> drivers -> usb_hid_drv] dev_info: input: USB HID v1.00 Mouse > [HID 04b4:0060] on usb-usbbus-/input0 > [init -> drivers -> usb_hid_drv] dev_info: input: USB HID v1.00 Device > [HID 04b4:0060] on usb-usbbus-/input1 > Kernel: MMU-fault not handled ESR=0x9261 > 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 have no idea why. The framebuffer, which is defined by u-boot, is > above the specified RAM. I get the expected graphics , so it works > that far. Two things can crash it. > 1) The Mouse > 2) Scout. > > I really want to add my own framebuffer using genode allocated ram.. > it might help. But I don't know how. > 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. Michael ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Dear Genodians, I start by mentioning that I am Jean-Adrien from Gapfruit. Sorry for the confusion I may create. I mailed you on my behalf today, with my private email address, to avoid interfering with any Gapfruit matter. I take your email, Norman, as an opportunity to share my enthusiasm about Genode. I may not have a significant contribution to make to the roadmap. But I would like to share some of my interests and motivation. This year I want to spend more time on contributions that can benefit the community. First, I will fix issues I have with my test machine to run Sculpt fully featured. Currently, networking via Wifi is not possible. Other difficulties may come after improving connectivity support. Next, I want to put effort into proposing 1) when I have finished with the 22.11 update integration and other work-related priorities. Then during my spare time, I would like to join efforts on support for Xen or Virt. Layer for Qube, adjusting myself to ongoing plans, if any exist? Following the "Roadmap 2023" discussion and after having a recent look at "Futur Challenges" [1] on the website, it is with lots of excitement that I found many subjects very close to my interests. Here are the topics: 1. Character device drivers as VFS plugins I proposed, some time ago [2], an SPI driver. The commits never made it to the staging branch because of the interfacing / "quality". Over time, at Gapfruit, we gained experience using the SPI bus, but only with TPMs. We recently refactored it into a VFS plugin for easier interfacing with libraries such as WolfTPM and TPM TSS. I believe BUS drivers such as I2C and SPI could be unified behind a standard "character device" VFS plugin interface. Can that benefit the community? I can put some effort into improving and contributing those commits. 2. Genode as virtualization layer for Qubes OS I am a daily user of Qube OS. Sculpt is an attractive alternative! Trying it out as a daily OS is part of my plans. I have little knowledge of the Qube OS internals, only that they use Xen as a hypervisor. I was surprised to find out about the hypervisor abstraction layer they created. It is a game changer for using Genode to build a virtualization layer. It brings so many questions to my mind. First, does full support for a hypervisor such as Xen need to find its way to Genode? Or is base-nova already a viable candidate? Are all necessary building blocks for AppVM message passing present within Genode? Which approach would you privilege first for investigation? If Xen, support for Genode in a Dom0 scenario first? Or, as an AppVM first, focussing on Qube RPC mechanism support? (I am aware of Xen DomU support, but I do not have all details in mind) Currently, those questions might be off-topic. Overall, it seems a significant challenge. 3. Xen as "Kernel" for Genode My ultimate goal here would be to have a pure minimal Genode-based OS in Dom0 for only managing guests' VM. Last summer, by curiosity related to 2), I started investigating necessary changes to the build system for building Xen as a port and generating a boot image using Xen with a Genode base-hw minimal scenario as Dom0. I was able to set up the port, successfully building Xen and booting it, but with a minimal Linux as Dom0 instead of a chosen Genode scenario "run/log," e.g. I still need to reach my goal. The real work only begins now. My primary technical motivation was working on low-level mechanisms to manage DomU(s) and enable RPC from one DomU to the other. I lost interest over time because I needed to be more confident in its relevance and missed lots of knowledge. At that time, I was unaware of the work of Julian Stecklina. I would be interested in looking into it! Is it publicly available? - Side note about the AMD Radeon drivers, my x86_64 test machine is an HP Elitebook 849 G2 equipped with an AMD Radeon R7 M260X. If some workforce is needed, I would also be happy to test and provide feedback! Another topic I was very interested in is initiatives like Spunky [3]. I am not making it a point as this is not to take as seriously as the others. With the gain of popularity from languages like, e.g. Rust. Is there any plan or similar initiative in that regard? I would be up to start one as a pet project. I am interested in trying this out with the Zig programming language [4]. My motivation for such a language comes from a Youtuber I appreciate [5]. He made an interesting video on memory safety within different languages [6]. I do not have any strong opinion on "C++ vs any other lang" topics. If you have other languages in mind, please let me know! Finally, thank you all for your supportive, kind and professional attitude! Since I started working with the Genode OS Framework, it has always been a pleasure to read from and interact with any of you. I am relatively junior to OS development. Thanks to my co-workers and following daily discussions on this m
Re: Roadmap 2023
Hi Pirmin, thanks a lot for your contribution to the road-map discussion! What directions are you most excited about? As I want to replace my main setup (Linux/KVM with virtual machines for different tasks) with a Genode system. I'm very interested in everything related to things that enable Genode to run on my main desktop machine. Two points that Alex brought up caught my attention: - Extended multi monitor - support for AMD GPUs. This I have on my task list for some time now, unfortunately I never had time to do it. The repeated interest in AMD during the road-map discussion cannot be dismissed. Even though I expressed my hesitation in my reply to Alex [1], I sense that the community interest in AMD deserves a mention on the official road map. My concerns can be addressed by presenting the topic as exploratory work. [1] https://lists.genode.org/pipermail/users/2023-January/008218.html An other point I'm interested in, is Genode on the PinePhone (mine should arrive on Friday). One thing I would want to use this for, is thedering in locations with no WiFi but LTE coverage. This can currently be done via the LAN port of the dock I think. It is so nice to see your interest in the PinePhone topic as well. For your specifc use case, the Wifi driver would be the most obvious piece missing so far. One point that is probably not that easy and further out, is the possibility to pass through a PCI device (Graphics cart) directly to a virtual machine. Another interesting topic to explore. The biggest challenge will certainly be the coupling of the the guest OS with the IOMMU to allow the guest OS to issue DMA transfers. So VBox must somehow interoperate with the platform driver who is the single authority over DMA memory now. ...interesting food for thought. Second, now that support to port libraries with Goa is nearing completion, I would like to use this to port neovim to Genode. Not that vim isn't enough to edit files. I would like to test out, what can be achieved that way. I'm grateful for your intensive work on this topic. Even though I have not yet reviewed your latest version, I sense that the library support has matured enough to be upstreamed soon. Do you think that we should aspire featuring it it in Genode 23.02? If so, I'd commit to focus on the review/finishing touches during February. 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 ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: Roadmap 2023
Hello Pirmin, > Most of my time working with Genode is related to my job. Privately i did > build a test machine to run Genode on. The onboard Nic of this machine isn't > supported by the ipxe network driver. Therefore I started porting the > intel_igc driver from Linux. I hope I can finish this soon. > The original plan was to port the AMD Radeon drivers (Framebuffer) from > Linux. This was interrupted by the intel_igc driver thou. Having a Linux-based ethernet driver for PC would be nice as I could piggyback on that with a RTL8125 driver (as that is also unsupported in iPXE). > If there is time left I would like to help in porting AMD Radeon drivers > from Linux and test them. Coincidentally I have started to port the 'amdgpu' driver as well. As that is also a pet project done in my spare time, the time frame is fuzzy. That being said, of course it would be nice to collaborated - I will contact you off-list. Regards Josef -- Josef Söntgen Genode Labs http://www.genode-labs.com/ · http://genode.org/ signature.asc Description: PGP signature ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
