[RPI BSP] cleaned up and reqest for review

[Gedare Bloom]

On Sun, Jun 14, 2015 at 6:31 AM, QIAO YANG <yangqiao0505 at me.com> 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
>
> I'll try to take a look at these.


> 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?
>
> I don't know the answer here. I suspect it would be easiest to use a
BSPOPT feature to get started.


> 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.
>
> I'm confused, do you mean printk always goes to the serial port? That's
probably OK.


> 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.
>
> Ok. One approach is to just run it and see what addresses it accesses. I
would have guessed either there is a specific memory region that is
well-known, or that there is a way to set the memory region yourself
through some mailbox.


> Something waiting to be done:
>
> 1. graphic console need the keyboard implementation . I would like to know
> the status of keyboard implementation.
>
> If you can use an SPI keyboard, I think this can be done easily/quickly.
USB keyboard probably won't be possible yet.


> 2. generate a bitmap font file instead of the one I used under GPL.
>
> 3. restructure the reusable code after the it's reviewed.
>
> OK.


> I will post a blog later for my works.
> I'll leave the commits for you to review.
>
> 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.
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150615/d9ae0332/attachment.html>