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

[Pavel Pisa]

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