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

[Sebastian Huber]

On 29/07/15 10:17, Pavel Pisa wrote:
> 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.

So the memory layout is mostly unknown at link-time? In this case a 
writeable MMU configuration table is indeed an option.

A custom workspace initialization can be done via 
bsp_work_area_initialize().

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.