[rpi bsp] configure fb section in mmu table and improvement for mailbox

[Pavel Pisa]

Hello Sebastian,

On Wednesday 29 of July 2015 09:06:47 Sebastian Huber wrote:
> On 28/07/15 02:31, Pavel Pisa wrote:
> >> >I think it's much closer to what we expected. you may checkout my
> >> > github and my dropbox. 
> >> >https://github.com/yangqiao/rtems/tree/framebuffer
> >> >https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl
> >> >=0
> >> >
> >> >The commits log is messy, I'll rebase it afterward until we think it's
> >> >acceptable.
> >
> > I think that Sebastian, Joel or some other core developer opinion
> > would be nice there.
>
> I don't have time to check out external repositories. I will only look
> at information included in e-mails posted to the devel list.
>
> I am not sure why you need additional sections in the MMU table for the
> frame buffer. In case it needs non-cachable memory, why don't you put it
> into the .bsp_nocache section?  You can also use a heap for this
> section, see rtems_cache_coherent_allocate().

I am not sure, if there is alternative way with .bsp_nocache section
and some request to reconfigure VideoCore memory placement/division.

Actual/standard way how RPi is used/setup is different.
The VideoCore detect/have specified actual amount of physical
memory then it reads "config.txt" file and reserves end
of memory for framebuffer and internal use. Operating system
has to adapt to that division.

So if RTEMS is intended to run on all RPi 1 boards with at least
two possible different amount of physical memory populated
and do not clash with user setup configs and some sizes
adjustment based (may be) even on VideoCore firmware version/binaries
then it needs to adapt to actual memory amount. Other option is
to use minimum for RTEMS application (i.e. 128 MB) and define rest
to 1 GB as noncacheable, but that is far from beeing ideal.

On the other hand, from my reading of CP15 setup the regions
size adaptation is not big problem. The end of heap/wokspace
should be adjusted as well. I have not looked into that,
but it should not be a problem/is resolved for other archs.

As for the code review, I understand you that inline patches
in email (until some size) are the best and that time is
great enemy. If you have some suggestion then I try
to guide Qiao Yang that direction.

To Qiao Yang, please, try to setup e-mail software/client
to send plain e-mails in the plain text format
and check that it does not clobber spaces, tabs and break
lines. The application of the patches in the case
of HTML formating is a problem. Your client sends text
version as well so it is not so critical and that can be used,
not sure about line wraps. But plain text would be better
for review.

Best wishes,

             Pavel


PS: I do not be available from August 7 to August 23.