[PATCH 2/3] bsp/csb336: Memory map update and jump to start at image start provided.

[Sebastian Huber]

On 2013-08-12 00:39, Pavel Pisa wrote:
> Hello Sebastian,
>
> thanks for fast application of the fix.
>
> On Friday 09 of August 2013 09:01:19 Sebastian Huber wrote:
>> Hello Pavel,
>>
>> thanks for your patches.
>>
>> On 2013-08-09 01:22, Pavel Pisa wrote:
>>>    - The first two megabytes of SDRAM unused by RTEMS are mapped
>>>      with attributes to allow specific purposes.
>>>
>>>      - the first MB (at address 0x08000000) is nocached to allow
>>>        directly set some values read by booot-block after warm reset
>>>
>>>      - the second MB (at address 0x08100000) is set for write-through
>>>        caching.  That allows to use memory for LCD frame-buffer without
>>>        need to flush cache after each redraw.
>>
>> This seems quite application specific.  Maybe add a BSP option to
>> configure.ac?
>
> It could be optional but the first 2 MB of SRAM are unused for all
> version of the BSP by RTEMS. Our actual PiMX1 loader does not require
> shifted start address of the load application. But I expect that
> original Cogent's CSB336 board use u-BOOT (and i.MXL does not provide
> eSRAM) so the first 2 MB reservation was required for u-boot.
>
> That area is unused by RTEMS, one to one access mapping is
> preserved (without full caching) so no existing application should
> have problem even if it reads some small amount of data passed over
> this area.
>
> And I think that it is reasonable to offer that (actually unused)
> area as good candidate for LCD framebuffer. Although, we use eSRAM
> in our actual application we consider i.MXS based variant and that
> would benefit from such change too.
>
> We can use application specific memory map or even bsp_start
> function but I think that it is better to use single setup which
> receives more testing and it simplifies others work if they want
> to follow our setup or generic framebuffer should be integrated
> into RTESM for CSB336. We use simple Microwindows driver
> which accesses "videoram" setup prepared by loader now.
>
> That is why I consider BSP option as unnecessary fragmentation.
> But if you think that it worth to be controlled by BSP option
> or directly by application we would addapt to that.

Ok, I checked it in as is.

>
>>> Jump to start provided at address 0x08200000 allows
>>> to load application image even as plain binary file
>>> and start it by jump to image start address.
>>>
>>> Signed-off-by: Pavel Pisa<ppisa at pikron.com>
>>
>> The RTEMS project has currently nothing to sign.
>
> Signed-off-by:
>
> is standard Linux kernel patch practice to declare that
> sender is the author or the patch or he proves other
> source (sender of patch) to be compliant with project license
> - GPL and that he passes patch in mainline direction
> in the maintainers hierarchy. It has nothing to do with
> assignment or other paperwork. So usual practise
> is that each developer and maintainer in the path
> to mainline adds his/her "Signed-off-by" approval
> before commit to his tree or send to other maintainer
>
> https://www.kernel.org/doc/Documentation/SubmittingPatches
>
> But I have nothing to omit this for RTEMS if it is
> not considered good practice.

I think this Linux policy is very useful.  Unfortunately the discussion of 
commit message formats in RTEMS was not very fruitful up to now.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.