BBB Framebuffer : Need Ideas.

Christian Mauderer list at c-mauderer.de
Fri Jul 12 15:01:58 UTC 2019


On 12/07/2019 13:57, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Thu, Jul 11, 2019 at 12:51 AM Christian Mauderer <list at c-mauderer.de
> <mailto:list at 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.mauderer at embedded-brains.de
>     <mailto:christian.mauderer at embedded-brains.de>
>     >> <mailto:christian.mauderer at embedded-brains.de
>     <mailto:christian.mauderer at 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
> 



More information about the devel mailing list