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

Thu Aug 6 22:52:43 UTC 2015

Hi Pisa Pavel,

On Aug 03, 2015, at 11:43 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:

> Hello Qiao Yang,
>
> On Monday 03 of August 2015 22:06:31 QIAO YANG wrote:
>> On Aug 03, 2015, at 08:34 AM, QIAO YANG <yangqiao0505 at me.com> wrote:
>> > On Jul 29, 2015, at 02:03 PM, Chris Johns <chrisj at rtems.org> wrote:
>> >> On 29/07/2015 8:04 pm, Sebastian Huber wrote:
>> >>> A custom workspace initialization can be done via
>> >>> bsp_work_area_initialize().
>> >>
>> >> On the zynq the ethernet driver from Ric (SLAC) for the in tree
>> >> (existing) IP stack there is:
>> >>
>> >> uint8_t* start;
>> >> size_t size = 0x100000;
>> >> uintptr_t boundary = (uintptr_t) 0;
>> >> uintptr_t alignment = (uintptr_t) 0x100000;
>> >> start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,
>> >> alignment,
>> >> boundary);
>> >> arm_cp15_set_translation_table_entries(start,
>> >> @start[size],
>> >> ARMV7_MMU_DEVICE);
>> >
>> > The arm_cp15_set_translation_table_entries function does help me to setup
>> > MMU entry at runtime.
>> >
>> > What exactly means the "boundary"? For exemple, is it possible to
>> > allocate the memory with a given start address(memory from 0xC100000 to
>> > 0xD100000)? Because in my case, the start address and its length is given
>> > by GPU.
>> >
>> > Actually, I've got everything worked without heap allocate and I've only
>> > setup the entry. Is it normal? I know little about how the memory managed
>> > and what happened here.
>>
>> I couldn't tell the difference between that I add a section in
>> arm_cp15_start_mmu_config_table, then change the start address, end address
>> to the right value, and that I add the entry at runtime. I didn't see any
>> allocation in both ways. Maybe I just need to setup the entry? Or maybe
>> what I've got is an undetermined result. 
>
> You do not need allocate space for tables dynamically.
> You adjust only single preallocated entry.
> There is no need to call
>
> rtems_heap_allocate_aligned_with_boundary
>
> But there are two different memory setup tasks which should be solves.
> One is the right setup of MMU to allow framebuffer access.
>
> The other is ensure that heap/malloc/workspace (generally system
> services which dynamicallyallocate memory for applications and kernel)
> know right limit, i.e. do not try to use range reserved for framebuffer
> to satisfy application needs.
>
> 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.

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

The memory split is setup with a min 16M and step of 8M , so no worry about 1M page step alignment.

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.

pre-compiled images are available in
https://www.dropbox.com/sh/hxzel2a70rqiwyz/AAB9g0pKB1zU5MdLCYJKC2H9a?dl=0

>
>
> So you should remove shared wokspace initialization
> from RaspberryPi Makefile.am. It should point now to, points to
>
> rtems/c/src/lib/libbsp/shared/bspgetworkarea.c
>
> and provide local copy of bsp_work_area_initialize() similar
> way as GBA (for ARM example) uses.
>
> rtems/c/src/lib/libbsp/arm/gba/startup/bspgetworkarea.c
>
> 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.

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.

>
> As for the CP15 table, you should get rid of connst by rename
>
> const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[];
>
> to
>
> const arm_cp15_start_section_config
> raspberrypi_arm_cp15_start_mmu_config_table[];
>
> Then you use only this name to adjust entry and call setup.
>
> The size can be left or renamed same way
>
> const size_t arm_cp15_start_mmu_config_table_size
>
> to
>
> const size_t raspberrypi_arm_cp15_start_mmu_config_table_size
>
> it can stay const because you prealocate the entry.
>
> Best wishes,
>
> Pavel

Best wishes,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150806/b98dcf20/attachment-0002.html>