[RPI BSP] fbcon implementation

[Pavel Pisa]

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 _RPI_initvideo
> and _RPI_outch, used to print chars to graphic. They are declared in bsp.h
> and implemented in outch.c as we've done in i386 bsp.
>
> 1. The _RPI_initvideo function need to initialize framebuffer driver and
> get the informations. I think it would not be logical nor safe if I don't
> 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 fb
> infos, it works but we will miss all output before the fb initialized.
> Another proposition, we would always let the driver itself to decide the
> 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 second
> 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 has
> 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. GRUB).
The same work for Linux kernel when booted from U-boot and RTEMS is
able to accept arguments for PowerPC and other BSPs.

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 option

  --video=<resX>x<resY>[-<bpp>]
  --video=auto - try connected monitor EDID to find best matching mode
  --video=none

You can find implementation in

  https://git.rtems.org/rtems/tree/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c

But bsp_cmdline_arg() is specific for i386 and I have not found equivalent
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 automatically
select mode according to EDID (reuse data structures from i386 possible)
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: after
> 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 not
> possible, like we've discussed earlier, we should enable all possible area
> 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 startup.

> 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 think
> maybe we can move the font file in a common directory for all bsps. It's
> 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
location.

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