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

[Pavel Pisa]

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.

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 );
}

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