Hi Pisa Pavel,
On Aug 03, 2015, at 11:43 AM, Pavel Pisa <p...@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 <yangqiao0...@me.com> wrote:
> On Jul 29, 2015, at 02:03 PM, Chris Johns <chr...@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,
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
