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

[Gedare Bloom]

On Fri, Aug 7, 2015 at 5:33 AM, QIAO YANG <yangqiao0505 at me.com> wrote:
>
>> On Aug 7, 2015, at 10:45 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
>>
>> Hello Qiao Ynag,
>>
>> I am in a hurry now.
>>
>> On Friday 07 of August 2015 00:52:43 QIAO YANG wrote:
>>>> You have the MMU part right. You know where VC memory starts.
>>>> You round it down to 1MB range (because that is step size which
>>>> ARM MMU provides in the actual RTEMS setup). Then you need to
>>>> limit or enlarge area which would be available for later memory
>>>> allocation support. The thing are safe if you limit memory
>>>> size by ldscript. But limiting to something like 128 MB of usable
>>>> memory is significant waste.
>>>
>>> if the limit RAM length setup in linkcmds is 128MB, I can't expend the
>>> working area to 256MB later in the code.
>>> It's only possible to initialize
>>> the work area with a smaller area.  All memory sections addresses are
>>> calculated based on RAM, setup in linkcmds. So it will not be possible to
>>> change the length of RAM later .I can't understand this behavior. If it's
>>> how it expected, I would say that the RAM length is a hard limit and I'll
>>> take the smaller one when setting up the work area.
>>
>> Your idea use  arm_cp15_set_translation_table_entries for VC memory
>> is good solution. But if the whole left memory should be used for
>> application, then it is necessary to cover rest of the memory by
>> ARMV7_MMU_DATA_READ_WRITE_CACHED translations. One option is to define
>> memory size big enough to initially write all translations
>> as ARMV7_MMU_DATA_READ_WRITE_CACHED or other option is to define
>> initial memory as 128 MB for instance and then use separate
>> call to arm_cp15_set_translation_table_entries() with
>> ARMV7_MMU_DATA_READ_WRITE_CACHED for area 128 MB start of VC area
>> and second call for VC area. I am not sure if ARMV7_MMU_DATA_READ_WRITE_CACHED
>> is a good idea for that area. I expect that video core access is not coherent
>> with CPU access. Then ARMV7_MMU_READ_WRITE should be used. It would be little
>> slower but safe.
>
> I’m not sure which flag is better. It’s easy to explain how the memory used.
>
> EX: gpu_mem= 128MB.
>
> Then we the memory from 0x1C000000 to the end will be reserved for gpu. All the rest are used for arm cpu(0x0 - 0x1c000000).
> So what I’ve done is to limit the end of workarea to  0x1C000000. So that we won’t corrupt the memory for gpu.
>
> I’ve added an entry in the MMU table is just for that we have the access to the fb memory, and actually the fb memory is in the gpu area (from 0x1E513000 with size 0x6E7000). So all in all, the gpu’s memory is reserved for gnu, and all memory can be used by cpu is from 0x0 to 0x1c000000.
>
> I didn’t mention cp15 table above. What I was trying to explain is that, the physical memory size is set in linkcmds, and it’s used to determine  how the memory used, ex: where starts the mmu table, interrupt table, etc and their size. If the RAM length is smaller, we can’t make use of full memory because I can’t expend it in runtime(maybe we can but if i set the RAM to 128MB in linkcmds, and try to initialize work area with 256M, system will stop). If the length is bigger, then it’s sure that some memory access are overflow. So user has to setup the RAM size when compiling, and after the board booted, I’ll limit the work area (0x1c000000, instead of all 0x20000000 memory) so that the os won’t allocate the memory located in gpu area(0x1c000000 - 0x20000000) for user. Isn’t it what you want me to take care of?
>
> I agree that I didn’t go further with the mmu flag, I’m not sure which would be appropriate.
>
Your approach sounds reasonable to me. The linkcmds creates the binary
executable and defines the needed/used memory sections of the entire
system (RTEMS+application). This means any memory that you want to
access from RTEMS/app must be included. The arm linkcmds.base puts the
workspace into the RAM region. There is plenty of memory available on
this board that the limits are not problematic. You can add another
entry into MEMORY after RAM_MMU for RAM_GPU, and define it starting at
the limits you have discussed above, and set the location of fb in the
linkcmds like how the location of the bsp_translation_table_base is
set.

Gedare