Re: [RPI BSP] resume, plan and questions for fb, fbcon gtk
Hello YANG Qiao, On Tuesday 05 of May 2015 01:08:11 QIAO YANG wrote: Since I haven't yet received any respond of my last mail and I've now got the names of mentors who would instruct me, I create a new thread for a simple resume and post my questions . First of all, I've managed to use mailbox channel to get a framebuffer pointer and its informations. I can draw some simple images with the pointer and also the pointer can be retrieved correctly by ioctrl from applications, with the fb device interface. Painting works as well. I've already sent a patch with mailbox implementation, but I haven't yet confirmed if it's ready to be merged or any modification should be done. To complete fb implementation: 1. Some more functions need to be added : connected monitor EDID read and decoding for correct/optimal resolution selection. I don't know if we need a full VESA driver like what we've done on i386. We do not need full VESA support but I suggest to look at EDID decoding and related header file which is part of i386 VBE driver. 2. If we've enabled l2 cache, the memory mapping would be 0x4000, while the mapping would be 0xC000 instead if l2 cache disabled. Normally it can be configured in the config.txt file. I am not sure there, I would expect address remapping only in the case that it is setup such way in the MMU. But MMU has to be enabled to enable cache on ARM (at least on models which I have used). The file 'config.txt' is read by GPU before the ARM core is initialized. It's used as an BIOS configuration. It can be used to setup hdmi output mode, l2 cache, memory split etc. Such as memory split affect much the range of framebuffer address which should be covered in the mmu configuration table. What would be a better way to deal with it? Should I enable the memory pages that cover all possible range(This can vary depend on gpu_mem_split) ? I you do not detect faramebuffer setup before MMU setup or use some RTEMS functions to setup that frame-buffer region later in the code during graphic driver startup then I suggest to setup (ideally 1 to 1) mapping for all possible regions. There could be problem with number of available TLBs but usually they are refilled from pagetable automatically so it has only impact on speed. But I need to look more to that. I have spent some time to read some more information about RPi VideoCore communication channel and work on preparation support acceptable for mainline Linux kernel. There are some links to share (I expect that you have read some of them but some can be new for you, check please) https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface https://github.com/hackerspace/rpi-linux/blob/e3a262a708820b7ee7b938637290e60ec6a784f6/drivers/mailbox/bcm2835-mbox.c https://github.com/raspberrypi/firmware To plan for fbcon implementation: 1. Find instructions for cursor. I've found that it's possible to get some infos from mailbox property channel. 2. Implementations refering to i386/pc386/console/outch.c 3. Implementations refering to i386/pc386/console/vgacons Cursor is not a must for start. Microwindows provide soft cursor for example. But if implemented then hardware cursor would help with speed a lot. For GTK porting Please, use RGTK for RTEMS Graphic Toolkit aka Microwindows or something else than GTK because I have association to attempt to port real GTK libraries set from the GTK name and taht would be instrresting but really huge job for more/many developers. I tried to compile gtk for it. The libpng ... etc can be installed and I'm trying to make some samples for testing. Only the nxlib failed to build because we haven't yet the keyboard support (mouse support can be switched off, but I can't find out yet how to build the lib without keyboard). It is possible to select keyboard driver named rtems-graphics-toolkit/microwin/src/drivers/kbd_null.c By the way, I have setup Microwindows repository with most of my changes and others RTEMS related changes. https://github.com/ppisa/microwindows When the school term/semester is over I hope to have some time for that and prepare changes which should be safe for Greg Haer main Microwinodws repository (now on GitHub) https://github.com/ghaerr/microwindows Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[RPI BSP] resume, plan and questions for fb, fbcon gtk
Hello everyone, Since I haven't yet received any respond of my last mail and I've now got the names of mentors who would instruct me, I create a new thread for a simple resume and post my questions . First of all, I've managed to use mailbox channel to get a framebuffer pointer and its informations. I can draw some simple images with the pointer and also the pointer can be retrieved correctly by ioctrl from applications, with the fb device interface. Painting works as well. I've already sent a patch with mailbox implementation, but I haven't yet confirmed if it's ready to be merged or any modification should be done. To complete fb implementation: 1. Some more functions need to be added : connected monitor EDID read and decoding for correct/optimal resolution selection. I don't know if we need a full VESA driver like what we've done on i386. 2. If we've enabled l2 cache, the memory mapping would be 0x4000, while the mapping would be 0xC000 instead if l2 cache disabled. Normally it can be configured in the config.txt file. The file 'config.txt' is read by GPU before the ARM core is initialized. It's used as an BIOS configuration. It can be used to setup hdmi output mode, l2 cache, memory split etc. Such as memory split affect much the range of framebuffer address which should be covered in the mmu configuration table. What would be a better way to deal with it? Should I enable the memory pages that cover all possible range(This can vary depend on gpu_mem_split) ? To plan for fbcon implementation: 1. Find instructions for cursor. I've found that it's possible to get some infos from mailbox property channel. 2. Implementations refering to i386/pc386/console/outch.c 3. Implementations refering to i386/pc386/console/vgacons For GTK porting I tried to compile gtk for it. The libpng ... etc can be installed and I'm trying to make some samples for testing. Only the nxlib failed to build because we haven't yet the keyboard support (mouse support can be switched off, but I can't find out yet how to build the lib without keyboard). That's all for a resume, plan, and questions report for my work. Best regards, YANG Qiao___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RPI BSP] resume, plan and questions for fb, fbcon gtk
Hi YANG Qiao and fellow mentors, On May 4, 2015, at 7:08 PM, QIAO YANG yangqiao0...@me.com wrote: Hello everyone, Since I haven't yet received any respond of my last mail and I've now got the names of mentors who would instruct me, I create a new thread for a simple resume and post my questions . First of all, I've managed to use mailbox channel to get a framebuffer pointer and its informations. I can draw some simple images with the pointer and also the pointer can be retrieved correctly by ioctrl from applications, with the fb device interface. Painting works as well. I've already sent a patch with mailbox implementation, but I haven't yet confirmed if it's ready to be merged or any modification should be done. I applied this patch and have commented that it compiles for me. I think new patches might be held up right now while the 4.11 release is sorted out. I am also working on a fork of the RTEMS tree with your mailbox patch, and I have re-integrated Andre’s GPIO, SPI, and I2C code, just to have the latest of everything for the RPI to this date. To complete fb implementation: 1. Some more functions need to be added : connected monitor EDID read and decoding for correct/optimal resolution selection. I don't know if we need a full VESA driver like what we've done on i386. I’m not too familiar with the VESA standard, does anyone else have an opinion? 2. If we've enabled l2 cache, the memory mapping would be 0x4000, while the mapping would be 0xC000 instead if l2 cache disabled. Normally it can be configured in the config.txt file. I would think we want to have L2 cache enabled by default. Any reason to support the frame buffer without the cache? The file 'config.txt' is read by GPU before the ARM core is initialized. It's used as an BIOS configuration. It can be used to setup hdmi output mode, l2 cache, memory split etc. Such as memory split affect much the range of framebuffer address which should be covered in the mmu configuration table. What would be a better way to deal with it? Should I enable the memory pages that cover all possible range(This can vary depend on gpu_mem_split) ? I’m not sure.. We probably need the MMU table before we start reading the configuration from the GPU mailbox, so it is hard to build the MMU table dynamically. Could we start with MMU disabled, query the mailbox API to determine the memory configuration, then setup the MMU? To plan for fbcon implementation: 1. Find instructions for cursor. I've found that it's possible to get some infos from mailbox property channel. 2. Implementations refering to i386/pc386/console/outch.c 3. Implementations refering to i386/pc386/console/vgacons For GTK porting I tried to compile gtk for it. The libpng ... etc can be installed and I'm trying to make some samples for testing. Only the nxlib failed to build because we haven't yet the keyboard support (mouse support can be switched off, but I can't find out yet how to build the lib without keyboard). That's all for a resume, plan, and questions report for my work. By GTK, are you referring to the RTEMS Graphics tool kit? ( not the GTK/gnome libraries right? ) Thanks for the update, As soon as I get all of the latest Raspberry Pi code together in my repository, I’ll let everyone know. Alan Best regards, YANG Qiao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
