BBB Framebuffer : Need Ideas.

Christian Mauderer list at
Wed Jul 10 19:21:51 UTC 2019

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
>> <mailto:christian.mauderer at>> 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
>>     >
>>     >
>>     > 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:
>>     >
>>     >
>>     > 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 :
>>     >
>>     >
>>     > 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:

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.

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


More information about the devel mailing list