[RPI BSP] fbcon implementation

[Joel Sherrill]

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
>_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.

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


http://wiki.beyondlogic.org/index.php?title=Understanding_RaspberryPi_Boot_Process

>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
>
>_______________________________________________
>devel mailing list
>devel at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel

--joel