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. > > 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. Best wishes, Pavel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
