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

[QIAO YANG]

> 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. 


> 
>> I've done many tests with different memory split and see the changes in
>> cmdline and also vc mailbox interfaces( get arm memory area tag and get vc
>> memory area tag).
>> 
>> With my rpi B/ B+, with 512MB memory:
>> 
>> cmdline:  vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000
>> arm mem base :0x0
>> arm mem size :0x8000000
>> vc mem base :0x8000000
>> vc mem size :0x8000000
>> fb base: 0xE513000
>> fb size: 0x6E7000
>> 
>> However I changed the gpu_mem in config.txt, the results above remained
>> always the same. Finally, it turns out to be an update of firmware.
>> 
>> * Please check out the latest firmware on github
>> https://github.com/raspberrypi/firmware/tree/master/boot you may need the
>> latest dtb, bootcode.bin, fixup.dat, and start.elf. I've tested them on my
>> boards.
>> 
>> arm base :0x0
>> arm size :0x1C000000
>> vc base :0x1C000000
>> vc size :0x4000000
>> fb base: 0x1E513000
>> fb size: 0x6E7000
> 
> I get to that when I return from trip.
> 
>> The memory split is setup with a min 16M and step of 8M , so no worry about
>> 1M page step alignment.
> 
> OK.
> 
>> BTW, I've found out why the latest firmware didn't work earlier. It was
>> because of the fb_mem base address returned by vc mailbox interface, didn't
>> add the memory mapping (0x40000000) while the new one added it on. So with
>> the previous code it can't work with the latest firmware. Now I updated the
>> code and I suggest you to use the latest firmware. I'll write it in a blog
>> later.
>>> The area_start is probably OK that the same way as GBA uses.
>>> Size should be computed as VC area star (limit) rounded down
>>> minus area_start.
>>> 
>>> void bsp_work_area_initialize(void)
>>> {
>>> void *area_start = (void *)&_end;
>>> uintptr_t area_size = (uintptr_t)&__heap_limit - (uintptr_t)&_end;
>>> 
>>> bsp_work_area_initialize_default( area_start, area_size );
>>> }
>> 
>> I didn't understand here.
>> I've just added the additional entry in mminit with function
>> arm_cp15_set_translation_table_entries and I didn't touch the cp15 config
>> table. What for we use another name of table here? If it's decalred with
>> const, I can't reserve a place and modify it for adaption later.
> 
> Idea has been to not use arm_cp15_set_translation_table_entries and use
> single call of arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache
> with writable table. But your alternative solution is probably better.
> The table is used only for that single call so it is not problem that
> it does not match exactly what has been setup later to MMU.
> 
>> As you will be absent from this weekend til the end of evaluation , it
>> would be better if we can verify what I've done by now so that this weekend
>> I can begin to cleanup all and work on the documents/blogs.
> 
> I hope that Gedare and others can help with hints.
> 
> Try to check if the cache can be used for VC and CPU shared area
> or if use of cache complicates the thing.
> 
> Test the code, it would be great if you try to contact students working
> on RPi 2 support to test your code etc. If you have free time
> you can try ATAGS or DT parsing but it is above project requirements.
> 
> Best wishes,
> 
>             Pavel