[RPI BSP] fbcon implementation

Joel Sherrill joel.sherrill at oarcorp.com
Tue Jun 2 21:48:07 UTC 2015

On June 2, 2015 5:45:07 PM EDT, Pavel Pisa <ppisa4lists at pikron.com> wrote:
>Hello Yang Qiao,
>On Tuesday 02 of June 2015 22:58:09 QIAO YANG wrote:
>> For the graphic text output, I've implemented two functions
>> and _RPI_outch, used to print chars to graphic. They are declared in
>> and implemented in outch.c as we've done in i386 bsp.
>> 1. The _RPI_initvideo function need to initialize framebuffer driver
>> get the informations. I think it would not be logical nor safe if I
>> declare the fb_init function as static and call it from outside.  If
>I just
>> wait for the initialization of fb driver, and expose getters for the
>> infos, it works but we will miss all output before the fb
>> Another proposition, we would always let the driver itself to decide
>> resolution and it won't change after the first init. Then the fb_init
>> function can be exposed to others (just return if it's called a
>> time) and it can be called at the bsp startup or somewhere else.
>> I haven't yet come up with a better idea. It would be great if anyone
>> any better solutions.
>I am not sure about RPi BSP but for i386 there is standard multiboot
>mechanism to pass arguments to booted kernel by boot loader (i.e.
>The same work for Linux kernel when booted from U-boot and RTEMS is
>able to accept arguments for PowerPC and other BSPs.

This looks to explain the source of the boot parameters on the Pi


>The kernel argument is used for graphic mode selection for VESA
>based graphic driver on i386 now. This is special case because
>mode has to be setup before RTEMS is fully started and IRQs enabled
>in this case so the mode can be only queried by application but
>not changed in this case. Mode is selected by "video" command line
>  --video=<resX>x<resY>[-<bpp>]
>  --video=auto - try connected monitor EDID to find best matching mode
>  --video=none
>You can find implementation in
>But bsp_cmdline_arg() is specific for i386 and I have not found
>for ARM by short glimpse.
>Because the RPi mailbox based FB control does not require to stop
>scheduller then mode selection can be left on frame_buffer_control()
>driver function. Option to check if monitor is connected and
>select mode according to EDID (reuse data structures from i386
>at RTEMS statrup would be nice and allows to use graphics for startup
>messages output immediately. The use of exact 1:1 pixel match to LCD 
>displays is the most usesfull resolution and mode selection today.
>> 2. The mmu configuration for framebuffer. I'm still confused about
>how to
>> deal with it.
>>     Is there anyway to setup the memory in the code ? For exemple:
>> detected the size and start point of framebuffer, setup a given block
>> (range) to  ARMV7_MMU_DATA_READ_WRITE in the code?
>>    I prefer to setup the mmu table after the fb initialized. If it's
>> possible, like we've discussed earlier, we should enable all possible
>> at startup. Since the start point varies for different devices, how
>can I
>> find out the pages to be activate?
>I believe that it is possible if space in page table is reserved at
>> 3. Not like in i386, I've got to take a ascii font file for drawing
>> characters. I've taken the hard cored 8*16 font from UBOOT code. I
>> maybe we can move the font file in a common directory for all bsps.
>> not so important, just a suggestion. Also the EDID header may be
>moved for
>> all bsps as well.
>I agree and suggest to put EDID header files to shared place where
>all BSPs can select/enable their copy to installed include files
>I expect, that next location is right
>  rtems/c/src/lib/libbsp/shared/include
>The font(s) should be moved to BSP independent location as well.
>So I agree with proposal. I am not sure about the best location.
>The location should be negotiated with RTEMS core developers ...
>Joel, Chris, Gedare, Sebastian. I suggest next location to have
>some start point for discussion
>  rtems/c/src/lib/libbsp/shared/fonts
>The U-boot taken file license can be a problem. But we have
>had tool to generate Micro Windows compatible font from
>TTF fonts and there are MPL or even less restrictive licensed
>fixed size fonts in Microwindows for example.
>So finding reasonable font wit suitable license should not be
>a problem.
>Best wishes,
>             Pavel
>devel mailing list
>devel at rtems.org


More information about the devel mailing list