[rpi bsp] configure fb section in mmu table and improvement for mailbox
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Jul 29 10:04:19 UTC 2015
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.
More information about the devel
mailing list