Also, Premysl should start FSF paperwork for submitting patches to GCC/binutils. -Gedare
On Sun, Mar 16, 2014 at 8:30 PM, Gedare Bloom <ged...@rtems.org> wrote: > Hi Pavel, > Hopefully Sebastian may comment as he is most familiar with ARM, but > here are my two cents: > > On Sun, Mar 16, 2014 at 7:40 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote: >> Hello everybody, >> >> we have a student (Premysl Houdek) who has interrest >> in ARM based embedded systems. He has long term experience >> with Cotex-M LPC based boards. >> >> He has not used RTEMS yet but he likes idea to test it, >> work on it and eventually use it in applications. >> > Have him do the GSOC getting started ASAP if he hopes to participate. > >> We have discussed possible summer and thesis projects >> and his preference is to try port RTEMS to Cortex-R4F / >> Ti's TMS570LS3137 . Advantage is that we have some boards >> based on this chip left at our university office from >> previous projects, we have already implemented support >> for CAN, FlexRay and other peripherals with use of >> Ti CCS and included rudimentary OS and we would be happy >> to test RTEMS as more complete operating system running >> on the HW. >> >> Other, more important reason for Cortex-R4 is that >> it is one of not so many safety enhanced CPUs. >> TMS570LS3137 includes two cores in lockstep mode with >> hardware differences comparison, full ECC SRAM and Flash >> and all peripherals registers and memories equipped >> by parity bits. >> >> There is not much MCUs which provide such setup. >> There are more such PowerPC based systems and there >> are much more expensive special chips for aerospace >> and space applications. But Ti's TMS570 and Hercules >> families are relatively new and some of these chips >> are quite affordable. RTEMS targets same/similar range >> of applications as these chips so I think there is >> good match. >> > All this sounds good. > >> My question: >> >> What is opinion of RTEMS development coordinators, >> do you suggest to open that task for GSoC application >> and student proposal evaluation? >> > On the surface, a new BSP is not usually going to be enough for GSoC, > unless it requires some modifications due to instruction-set > differences at the architecture level. If R4 requires some different > assembly code for context-switch and interrupt handling than what > exists already, then there could be enough work to cover the summer. > That said, including support for the cache management and MMU/MPU (if > one exists) can also be proposed as optional time-fillers, or some > other peripherals. > >> If yes, then who is willing to be menthor/reviewer? >> I expect to be co-menthor or consultant. There are > We would find a mentor, and let you be a co-mentor, if it would get accepted. > >> more other people at our department who already >> finished thesis or project related to given HW, so there >> is knowledge base for work. There is high chance that >> student would continue on project because he consider >> to choose it as diploma thesis and so final state should >> be very well documented and integrated at the end. >> >> As for the GSoC period, I expect next goals >> >> - basic test and toolchain configuration >> non-multilib version for Cortex-R4 big-endian should >> not be problem for GCC >> >> - documented patch for addition of the variant into multilib >> >> - checking which conditional blocks in RTEMS ARM SCORE >> sources best match architecture and providing patch >> to select appropriate SCORE support. >> >> - extensions of SCORE (task switch and interrupts) to support >> the architecture >> >> - implementation of serial port driver - ideally interrupt driven >> > Clock driver should be accomplished also. > >> Then other peripheral support can be implemented during diploma >> thesis period, including basic CAN and FlexRay support. Porting >> of our Matlab/Simuling Embedded Coder target base environment >> to RTEMS POSIX or RTEMS specific API should be reachable as well. >> >> More about related project for actual used OS there >> >> http://rtime.felk.cvut.cz/rpp-tms570/ >> >> More about MCU there >> >> http://rtime.felk.cvut.cz/hw/index.php/TMS570LS3137 >> >> The concrete board design is owned by carmaker which >> contracted us to do the design for new potential MCU platform >> suitability test. But we have some code originally running >> on Ti's evaluation kit. It was broken during other diploma >> thesis but I expect that we can get another one from Ti >> so we should provide even BSP variant for HW which has >> full public documentation and is available from Ti. >> > It is necessary to provide the BSP variant for the available board. I > am not interested in funding development of BSPs for non-public > boards. Is there any possible simulator targets that can be considered > for this project? RTEMS Project should have some way to test the code > especially for SCORE additions. > > -Gedare > >> Thanks for reply or ideas even for different project >> in advance. >> >> Best wishes, >> >> Pavel Pisa >> e-mail: p...@cmp.felk.cvut.cz >> www: http://cmp.felk.cvut.cz/~pisa >> university: http://dce.fel.cvut.cz/ >> >> PS: I am on yet another exhibition (Amper in Brno) next week >> so my response can lag some days _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
