On June 2, 2015 5:45:07 PM EDT, Pavel Pisa <ppisa4li...@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@rtems.org >http://lists.rtems.org/mailman/listinfo/devel --joel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
