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<pp...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
