[RPI BSP] cleaned up and reqest for review

Joel Sherrill joel.sherrill at oarcorp.com
Mon Jun 15 13:39:15 UTC 2015



On 6/14/2015 5:31 AM, QIAO YANG wrote:
>
> Hello sirs,
>
> I've cleaned up my works for fb implementation and the graphic console. Now it's available on my github:
>
> mailbox: https://github.com/yangqiao/rtems/commit/4b4239135d23d82c2a284c8c848d8f97cd3c5e41
> videocore: https://github.com/yangqiao/rtems/commit/38c26a49126e5cff92ae389dba252cb180362c90
> fb : https://github.com/yangqiao/rtems/commit/979a15412f84f8b0095a613d66cddbc3ca777efc
> outch: https://github.com/yangqiao/rtems/commit/858a9b091025acc4bfe912f41d70c9a73b99d773
> fbcons: https://github.com/yangqiao/rtems/commit/1d82ef8ff28e0ef6a062313ca4874fe720a32e6e
>
> A screen shot for the graphic text console is in attachment.
>
> Still some problem I've got difficulties to solve :
>
> 1. Will rpi bsp has any kernel command line setup like i386? This would let us to choose fb console port or serial console port . Or maybe we just use compiler macro to enable/disable graphic console output?

How does the Linux kernel get its boot arguments? The pc386 BSP gets its arguments the same way.
Then there are some bsp command line methods to access the parameters. The start code passes a
string pointer to boot_card for this to happen.

> 2. I've found that printk don't output to serial port instead of fbcons even if I've set up the BSPPrintkPort to the fb console. Is it acceptable or what I missed in the console implementation? I've read through the i386 bsp but I can't find out the reason.

There must be a missing switch here. The logic to get them separated is always BSP specific
and can be tricky. Likely whatever you are doing is being overridden.

The code doing this for the pc386 is in console_select.c. It is likely that the boot arguments
will need to distinguish between printk and console device.


> 3. I still have no idea on  how can I find out all possible fb buffer's location as we need to enable the segment of memory in mmu configuration. I can find few document on how the cpu allocate the buffer. I'm trying to ask other communities, forums.
>
> Something waiting to be done:
> 1. graphic console need the keyboard implementation . I would like to know the status of keyboard implementation.
>
> 2. generate a bitmap font file instead of the one I used under GPL.
>
> 3. restructure the reusable code after the it's reviewed.
>
> I will post a blog later for my works.
> I'll leave the commits for you to review.fbcons.png
>
> On Jun 07, 2015, at 10:53 PM, QIAO YANG <yangqiao0505 at me.com> wrote:
>
>> Hi,
>>
>> I've got a few questions over the fbcons implementation details and edid lecture:
>>
>> 1.  I should place the video init function where exactly? In the end of bspstarthooks.c  hook_1() or in the bspstart.c ?
>>
>> 2.  I need to ensure the structure buffer is 16-byte aligned .  I use __attribute__((aligned (16))) to specific the alignement. Is there any rtems macro for this or it's ok that I use the compiler attribute for all structure definition?
>>
>> 3. Is it necessary to encapsule the communication with videocore interfaces with individual functions? Or just let the developper construct the buffer to send in a certain structure with the macros defined?
>>
>> 4. I've read many others' implementations of framebuffer. I've found that they all just query the display size by the videocore interface and use that for the resolution setup. So I wonder if it's obliged to get the EDID blocks, parse it then decide the resolution.  I proposed that we try to get the resolution from cmdline setup, use it if it's supported. If the setup is not supported, we'll query the display size. Normally the query can't fail as all others will throw an error when the query failed and stop the fbinit in their code (except for qemu emulator,  width=0,height= 0 will be returned) . If the query does fail, we will then try the default resolution: 640*480.
>>
>>
>> For now, I think I've just need some more time to cleanup, write test samples and then send patches. If everything's ok next week I'll move to test and adapt the graphic libraries.
>>
>>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


More information about the devel mailing list