[PATCH 2/3] bsp/csb336: Memory map update and jump to start at image start provided.
sebastian.huber at embedded-brains.de
Wed Aug 14 14:31:00 UTC 2013
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
> 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.
> 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
> 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.
More information about the devel