<html><body><div>Hi Pisa Pavel,<br><br>On Aug 03, 2015, at 11:43 AM, Pavel Pisa <<a onclick="return false;" href="mailto:pisa@cmp.felk.cvut.cz" data-mce-href="mailto:pisa@cmp.felk.cvut.cz">pisa@cmp.felk.cvut.cz</a>> wrote:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content">Hello Qiao Yang,<br><br>On Monday 03 of August 2015 22:06:31 QIAO YANG wrote:<br></span></span><blockquote class="quoted-plain-text" type="cite">On Aug 03, 2015, at 08:34 AM, QIAO YANG <<a onclick="return false;" href="mailto:yangqiao0505@me.com" data-mce-href="mailto:yangqiao0505@me.com">yangqiao0505@me.com</a>> wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">> On Jul 29, 2015, at 02:03 PM, Chris Johns <<a onclick="return false;" href="mailto:chrisj@rtems.org" data-mce-href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">>> On 29/07/2015 8:04 pm, Sebastian Huber wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">>>> A custom workspace initialization can be done via</blockquote><blockquote class="quoted-plain-text" type="cite">>>> bsp_work_area_initialize().</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>> On the zynq the ethernet driver from Ric (SLAC) for the in tree</blockquote><blockquote class="quoted-plain-text" type="cite">>> (existing) IP stack there is:</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>> uint8_t* start;</blockquote><blockquote class="quoted-plain-text" type="cite">>> size_t size = 0x100000;</blockquote><blockquote class="quoted-plain-text" type="cite">>> uintptr_t boundary = (uintptr_t) 0;</blockquote><blockquote class="quoted-plain-text" type="cite">>> uintptr_t alignment = (uintptr_t) 0x100000;</blockquote><blockquote class="quoted-plain-text" type="cite">>> start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,</blockquote><blockquote class="quoted-plain-text" type="cite">>> alignment,</blockquote><blockquote class="quoted-plain-text" type="cite">>> boundary);</blockquote><blockquote class="quoted-plain-text" type="cite">>> arm_cp15_set_translation_table_entries(start,</blockquote><blockquote class="quoted-plain-text" type="cite">>> @start[size],</blockquote><blockquote class="quoted-plain-text" type="cite">>> ARMV7_MMU_DEVICE);</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> The arm_cp15_set_translation_table_entries function does help me to setup</blockquote><blockquote class="quoted-plain-text" type="cite">> MMU entry at runtime.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> What exactly means the "boundary"? For exemple, is it possible to</blockquote><blockquote class="quoted-plain-text" type="cite">> allocate the memory with a given start address(memory from 0xC100000 to</blockquote><blockquote class="quoted-plain-text" type="cite">> 0xD100000)? Because in my case, the start address and its length is given</blockquote><blockquote class="quoted-plain-text" type="cite">> by GPU.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> Actually, I've got everything worked without heap allocate and I've only</blockquote><blockquote class="quoted-plain-text" type="cite">> setup the entry. Is it normal? I know little about how the memory managed</blockquote><blockquote class="quoted-plain-text" type="cite">> and what happened here.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">I couldn't tell the difference between that I add a section in</blockquote><blockquote class="quoted-plain-text" type="cite">arm_cp15_start_mmu_config_table, then change the start address, end address</blockquote><blockquote class="quoted-plain-text" type="cite">to the right value, and that I add the entry at runtime. I didn't see any</blockquote><blockquote class="quoted-plain-text" type="cite">allocation in both ways. Maybe I just need to setup the entry? Or maybe</blockquote><blockquote class="quoted-plain-text" type="cite">what I've got is an undetermined result. </blockquote><span class="body-text-content"><br>You do not need allocate space for tables dynamically.<br>You adjust only single preallocated entry.<br>There is no need to call<br><br> rtems_heap_allocate_aligned_with_boundary<br><br>But there are two different memory setup tasks which should be solves.<br>One is the right setup of MMU to allow framebuffer access.<br><br>The other is ensure that heap/malloc/workspace (generally system<br>services which dynamicallyallocate memory for applications and kernel)<br>know right limit, i.e. do not try to use range reserved for framebuffer<br>to satisfy application needs.<br><br>You have the MMU part right. You know where VC memory starts.<br>You round it down to 1MB range (because that is step size which<br>ARM MMU provides in the actual RTEMS setup). Then you need to<br>limit or enlarge area which would be available for later memory<br>allocation support. The thing are safe if you limit memory<br>size by ldscript. But limiting to something like 128 MB of usable<br>memory is significant waste.</span></div></div></blockquote><span><br>if the limit </span><span>RAM length setup in linkcmds is 128MB, I can't expend the working area to 256MB later in the code. </span>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.<br><br>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).<br><br>With my rpi B/ B+, with 512MB memory:<br><br>cmdline: vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000<br>arm mem base :0x0<br>arm mem size :0x8000000<br>vc mem base :0x8000000<br>vc mem size :0x8000000<br>fb base: 0xE513000<br>fb size: 0x6E7000<br><br>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.<br><br>* Please check out the latest firmware on github <a href="https://github.com/raspberrypi/firmware/tree/master/boot" data-mce-href="https://github.com/raspberrypi/firmware/tree/master/boot">https://github.com/raspberrypi/firmware/tree/master/boot</a><br>you may need the latest dtb, bootcode.bin, fixup.dat, and start.elf. I've tested them on my boards.<br><br>arm base :0x0<br>arm size :0x1C000000<br>vc base :0x1C000000<br>vc size :0x4000000<br>fb base: 0x1E513000<br>fb size: 0x6E7000<br><br>The memory split is setup with a min 16M and step of 8M , so no worry about 1M page step alignment. <br><br>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.<br><br>pre-compiled images are available in <br>https://www.dropbox.com/sh/hxzel2a70rqiwyz/AAB9g0pKB1zU5MdLCYJKC2H9a?dl=0<br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>So you should remove shared wokspace initialization<br>from RaspberryPi Makefile.am. It should point now to, points to<br><br>rtems/c/src/lib/libbsp/shared/bspgetworkarea.c<br><br>and provide local copy of bsp_work_area_initialize() similar<br>way as GBA (for ARM example) uses.<br><br>rtems/c/src/lib/libbsp/arm/gba/startup/bspgetworkarea.c<br><br>The area_start is probably OK that the same way as GBA uses.<br>Size should be computed as VC area star (limit) rounded down<br>minus area_start.<br><br>void bsp_work_area_initialize(void)<br>{<br> void *area_start = (void *)&_end;<br> uintptr_t area_size = (uintptr_t)&__heap_limit - (uintptr_t)&_end;<br><br> bsp_work_area_initialize_default( area_start, area_size );<br>}<br></span></div></div></blockquote><span> </span><br><br>I didn't understand here. <br>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.<br><br><br>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.<br><br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br>As for the CP15 table, you should get rid of connst by rename<br><br> const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[];<br><br>to<br><br> const arm_cp15_start_section_config <br> raspberrypi_arm_cp15_start_mmu_config_table[];<br><br>Then you use only this name to adjust entry and call setup.<br><br>The size can be left or renamed same way<br><br> const size_t arm_cp15_start_mmu_config_table_size<br><br>to<br><br> const size_t raspberrypi_arm_cp15_start_mmu_config_table_size<br><br>it can stay const because you prealocate the entry.<br><br>Best wishes,<br><br> Pavel</span></div></div></blockquote><span> </span><br><br>Best wishes,<br></div></div></body></html>