On 12/07/2019 13:57, Vijay Kumar Banerjee wrote: > > > > On Thu, Jul 11, 2019 at 12:51 AM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> wrote: > > On 10/07/2019 12:53, Christian Mauderer wrote: > > > > > > On 10/07/2019 12:38, Vijay Kumar Banerjee wrote: > >> > >> > >> On Wed, Jul 10, 2019 at 12:40 PM Christian Mauderer > >> <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > >> <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>>> wrote: > >> > >> On 09/07/2019 21:13, Vijay Kumar Banerjee wrote: > >> > Hello all, > >> > > >> > First the status : > >> > * The fbd has been ported and it's attaching with the fb0 > devie. > >> There's > >> > an fb0 device entry created. > >> > * In the following commit I have added mmap to libbsd. This > works > >> like a > >> > wrapper to the mmap in cpukit > >> > > >> > : > https://github.com/thelunatic/rtems-libbsd/commit/a8fc3b2b6840465029a000cc4169e9efbd551097 > >> > > >> > Blocker : > >> > * After the fb0 is created and mmap is added, I don't see > anything on > >> > the screen. From the FreeBSD, it seemed like the VT > driver is needed > >> > and that is responsible for turning on the screen. So I > have ported a > >> > minimal version of the VT with only the initialization and > >> allocate parts: > >> > > >> > > https://github.com/thelunatic/rtems-libbsd/commit/95279e116717973525b581ae2e9550d1d3b8e1ba > >> > > >> > But even after porting the VT driver which initializes well > ( As the > >> > message during booting says). I don't see anything on the > screen. > >> > I need some ideas on what is missing or how to debug this. > >> > > >> > The app I'm using to test framebuffer is pushed here : > >> > > https://github.com/thelunatic/rtems-bbb/tree/master/apps/fb-sample > >> > > >> > Any idea regarding this is greatly appreciated. > >> > > >> > Thanks, > >> > Vijay > >> > > >> > >> Hello Vijay, > >> > >> did you have a look at the SPI of the HDMI framer? What is it > used for > >> according to the data sheet? Is it necessary for the driver? > >> > >> Hi, > >> From the datasheet, it seems that the SPI1_CS0 and SPI1_D0 pins are > >> configured as I2S interface for the audio. I think this is not > necessary > >> and it is enabled only for a few selected resolutions that > support audio. > >> > >> From our chat discussions and my own tests I know that the > screen is > >> still not receiving a signal. So I would assume some quite basic > >> problem. If your new mmap wouldn't work, you should still get > at least a > >> black screen. > >> > >> I was also hoping that VT will do the initialization and turn the > screen On. > >> There might be something useful that I omitted during the > porting. If you > >> can please review the commit, I can send it in the devel. > > > > I think in this case it's enough on your github repo. > > > > I haven't found anything yet. I'll try to have a more detailed look as > > soon as possible. But I'll be busy with some other topics today > > (including the evening). So most likely I can't tell much till > tomorrow. > > > > You might want to have a look whether you find some documentation for > > the graphics IP core in the TI chip. It could be interesting to have > > some documentation to see the basic steps. Maybe this gives a hint. An > > alternative could be to look at some other drivers (Linux, maybe > U-Boot > > or some embedded systems if there is one) to find out something more. > > There should be some sequence for the setup. If you know that sequence > > you can try to find it in the libbsd driver and see whether all steps > > are done. > > > > Although I don't have put much time into it today I had a look at the > original commit that added the FreeBSD am335x_lcd driver: > 8cfe669b84fdbf7d9f1312c50c39b663d68be85c > > The author added not only am335x_lcd.c but am335x_lcd_syscons.c too. > >From a look at it, most of it is a system console (like the name > suggests) and won't be useful for the current step. But the syscons_init > caught my eye: > > There is a call to vid_register in it. This function is declared in > sys/dev/fb/fbreg.h and defined in sys/dev/fb/fb.c. According to the > comment in the c file it "Registers a video adapter". I haven't seen a > call to that function in the ported code. > > I have imported the file but I can't reach any am335x_syscons* functions > from the debugger. The am335x_syscons_configure is supposed to call > the init function which calls the vid_register. The am335x_syscons creates > a DATA_SET with the macro VIDEO_DRIVER with the configure function. > Is it supposed to be linked somewhere that I'm missing?
Hello Vijay, it seems there is no "MODULE" macro in the am335x_lcd_syscons.c. But there are three others that look intersting: VIDEO_DRIVER(am335x_syscons, am335x_sysconsvidsw, am335x_syscons_configure); RENDERER(am335x_syscons, 0, am335x_rend, gfb_set); RENDERER_MODULE(am335x_syscons, gfb_set); Did you have a look at how they are defined? From a quick look they create three data sets and one module. You'll have to link in the module. Most likely you should have a look where the data sets are used. Sometimes another module or subsystem loops over such data sets and does some initialization with it. Best regards Christian > > So maybe it would be worth a try to port the lcd_syscons.c too. Maybe > even instead of the (not working) VT driver. Like for the VT, you most > likely can just remove everything that's console related in case it > makes problems. The relevant function should be syscons_init. > > Best regards > > Christian > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
