<div>19.03.2017, 23:51, "Pavel Pisa" <ppisa4lists@pikron.com>:</div><blockquote type="cite"><p>Hello Mr. Ahmed Asif,<br /><br />On Tuesday 14 of February 2017 09:19:07 AHMED, Asif wrote:</p><blockquote> Hello Mr. Sebastian Huber and everyone,<br /><br /> Thank you for your help. I could make the rtems application (rtems-app.exe)<br /> for big endian tms570. Now that I have got the steps right, I would like to<br /> make simple rtems application for the board I have, which is TMS570lc4357<br /> HDK which contains arm cortex-r5 processor. That's why I wanted to get the<br /> basic tms570ls3137 application right. I have read that It is possible to<br /> use TMS570ls3137_hdk_sdram or TMS570ls3137_hdk_intram configuration while<br /> the when board is setup by<br /> <a href="https://github.com/hornmich/tms570ls3137-hdk-sdram">https://github.com/hornmich/tms570ls3137-hdk-sdram</a> initialization code in<br /> the Flash. I would like to start from there so that I can initialize my<br /> TMS570lc4357 HDK board using TI's HALCoGen. I have checked that lc4357 and<br /> ls3137 both the boards use same ISSI 442S16400F SDRAM CHIP. It would be a<br /> great help if you could guide me to steps to follow. I have created one<br /> sdram_sci_configuration ccs project for my lc4357 board similar to that<br /> link and changed the linker cmd file of bsp. I can do the bsp clock and<br /> other simple changes. But I am not sure how to integrate rtems application<br /> or what to do next? What should be my next step to keep the initialization<br /> in the flash and run rtems application from intram or sdram?</blockquote><p><br />I would start first with links to TMS570 RTMES resources where I have tried<br />to track and collect our knowledge and achievements of my work with<br />Czech Technical University students on RTEMS port for TMS570.<br /><br />I am sending copy to Nikolay Komashinskiy who expresses interrest to work<br />on target during this year GSoC to coordinate effort and knowledge base.<br /><br />There is page in RTEMS wiki<br /><br />  <a href="https://devel.rtems.org/wiki/TBR/BSP/Tms570">https://devel.rtems.org/wiki/TBR/BSP/Tms570</a><br /><br />There are some remarks about debugging on the page<br /><br />  <a href="https://devel.rtems.org/wiki/Debugging/OpenOCD/TMS570">https://devel.rtems.org/wiki/Debugging/OpenOCD/TMS570</a><br /><br />more hardware remarks and stuff related to our actually<br />used development kit boards and our own board developed<br />as CPU test for one prime carmaker can be found<br />on our university local page<br /><br />  <a href="https://rtime.felk.cvut.cz/hw/index.php/TMS570LS3137">https://rtime.felk.cvut.cz/hw/index.php/TMS570LS3137</a><br /><br />The recapitulation of the BSP state and things which worth<br />to be done. The initial porting of RTEMS to TMS570<br />has been done by Premysl Houdek, my GSoC and then diploma<br />thesis student. The work repository there<br /><br />  <a href="https://github.com/AoLaD/rtems/tree/tms570-bsp">https://github.com/AoLaD/rtems/tree/tms570-bsp</a><br /><br />He is now even employed at our inivesity<br />group (<a href="http://industrialinformatics.cz/">http://industrialinformatics.cz/</a>) but all his<br />duties as employee at university are not related to TMS570,<br />he works on autonomous driving with future Nvidia ARM chips.<br /><br />All valuable TMS570 results of his work and my further<br />enhancements has been included in RTEMS mainline.<br />So RTEMS mainline is the right start point.<br /><br />The BSP can be build in multiple variants. If the basic<br />Flash start at zero address variant (tms570ls3137_hdk)<br />is build with TMS570_USE_HWINIT_STARTUP=1 configure option<br />than all code to bring-up all RTEMS supported peripherals<br />on TMS570LS3137 is included. The optional initialization<br />code is based on HalCoGen generated code but it has<br />been allmost completely rewritten to make it more readable,<br />allow to use same algorithms for chip with different sets<br />of peripherals etc. My longer term plan/dream is to support<br />TMS570LC4357 and evensome RM48 chips from the same code<br />base. The idea is to use common codebase, ideally even<br />the prebuild BSP and only select actually integrated<br />set of peripherals by tables provided by application<br />configuration. See how parity self test is implemented<br />to allow select peripherals to test by single table<br /><br />  <a href="https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest_parity.c">https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest_parity.c</a><br /><br />The same for default pins functions setup which can<br />be modified if user application provides own<br />tms570_pinmux_init() function and pins functions list<br />using include for given chip/application variant. See<br /><br />  <a href="https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c">https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c</a><br /><br />I think that state of integrated HW initialization<br />is in good shape for all peripherals except for SDRAM<br />init where I have some issues and have not time to<br />find the problem. Actual init is one to one to HalCoGen<br />code but there are issues for first invocation after<br />power up reset. The initialization is correct for subsequent<br />ones and I have not any time to llok at this more.<br />Strange is that the same code in separate initialization<br />build by Ti CCS compiler from HalCoGen sources<br /><br />  <a href="https://github.com/hornmich/tms570ls3137-hdk-sdram">https://github.com/hornmich/tms570ls3137-hdk-sdram</a><br /><br />works correctly. It is even more surprising because<br />their (Ti) original code does not use volatile and other<br />mechanisms to ensure correct compilation and CPU memory<br />barriers so according to C memory ordering standards it<br />is only coincidence that it works at all.<br /><br />There are even other options how to load and run<br />RTEMS application image on TMS570.<br /><br />1) Simple HW initialization and jumping to the RTEMS<br />or loading of application by JTAG. This has been<br />mode for the most of the RTEMS BSP development.<br />We used setup code which ends in the infinite loop<br /><br />  <a href="https://github.com/hornmich/tms570ls3137-hdk-sdram">https://github.com/hornmich/tms570ls3137-hdk-sdram</a><br /><br />and then used OpenOCD to load (tms570ls3137_hdk_sdram)<br />application to SDRAM or for short tests internal RAM<br />(tms570ls3137_hdk_intram).<br /><br />2) Use of XCP (automotive standard) FLASH loader and<br />boot code. The code is based on minimal FreeRTOS<br />application and allows to load application into Flash<br />or with small changes even into SDRAM by tool over<br />ETHERNET (TCP/IP, LwIP based). Code has been developed<br />by my coolegues at university as future step or our<br />large paid project.<br /><br />  <a href="http://rtime.felk.cvut.cz/rpp-tms570/">http://rtime.felk.cvut.cz/rpp-tms570/</a><br /><br />I would be very happy if boot loader part of that code can<br />be opensourced but there is significant work and money<br />investment by my our group and and conditions of such support<br />has to be negotiated with our group head.<br /><br />3) Direct integration of HalCoGen code to the RTEMS application.<br />I have done this experiment and pushed it to Premek's/our<br />TMS570 test repository (tms570-bsp-with-hwinit)<br /><br />  <a href="https://github.com/AoLaD/rtems/tree/tms570-bsp-with-hwinit/c/src/lib/libbsp/arm/tms570">https://github.com/AoLaD/rtems/tree/tms570-bsp-with-hwinit/c/src/lib/libbsp/arm/tms570</a><br /><br />This is only interesting code in that repository which<br />has not been included in mainline. I can imagine that stub for<br />this option can be included in mainline after some more cleanups<br />but I am personally against pushing any HalCoGen single board/configuration<br />hardcoded generated code into maniline. But it can be used for fast<br />start or some company hacked non portable application.<br /><br />We implemented ETHERNET driver and ported LwIP to TMS570.<br />The port of LwIP is part of our other project<br /><br />  <a href="https://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/">https://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/</a><br /><br />I think that working on LwIP integration is the must<br />for RTEMS for memory constrained targets. The BSD based<br />networking stack does not fit into 3 MB of Flash,<br />external RAM is slow on TMS570LS3137 and there is no<br />chance to run BSD stack with less than 2 or 4 MB of Flash.<br />There is my analysis how to make LwIP the first class citizen<br />of RTEMS<br /><br />  <a href="https://devel.rtems.org/wiki/Packages/LWIP">https://devel.rtems.org/wiki/Packages/LWIP</a><br /><br />The LwIP can be used without this but you cannot use fprintf<br />and other file handle related functions with it when not integrated.<br />Use of lwip_socket, lwip_read etc is required for now.<br /><br />As for the TMS570LC4357, this chip matches RTEMS nicely.<br />It has large enough Flash and RAM for many applications and even<br />external SDRAM memory can provide usable bandwidth thanks to the<br />cache addition.<br /><br />Texas Instruments have donated me one this board and it is<br />on my long list of task in the category would be nice to<br />do or waits for some paid project at university or company<br />which would enhance priority of that work.<br /><br />I have thought about future compatibility with TMS570LC4357 during<br />most of my TMS570 work and even done some preparation steps.<br />The code for pin multiplexer included in RTEMS mainline is prepared<br />for new style with separated innput and output switching matrix<br />found on TMS570LC4357. Even tools for parsing of Ti's manuals<br />and preparation of TMS570 BSP pins matrix description are prepared<br />for this setup<br /><br />  <a href="https://github.com/AoLaD/rtems-tms570-utils/tree/master/headers/terminals-pins">https://github.com/AoLaD/rtems-tms570-utils/tree/master/headers/terminals-pins</a><br /><br />and I have tuned manual parsing and have prepared RTEMS pinmux<br />compatible experimental/untested headers on my computer.<br />I can push this WIP on tms570lc4357-pins.h file into mainline<br />if there is negotiated how next steps for TMS570 BSP<br />are coordinated and results tested.<br /><br />It would worth to prepare equivalent of<br /><br /> <a href="https://github.com/hornmich/tms570ls3137-hdk-sdram/tree/master/SDRAM_SCI_configuration">https://github.com/hornmich/tms570ls3137-hdk-sdram/tree/master/SDRAM_SCI_configuration</a><br /><br />for TMS570LC4357 . I would prefer GCC based in this case.<br />I have not tested if I can use my OpenOCD based tools for TMS570LC4357<br />chip directly or if it requires more development. Unfortunately<br />my enhancements required for OpenOCD to allow Flashing and debugging<br />of SDRAM applications are based on Andrey Smirnov OpenOCD branch<br />which has not been accepted to mainline. So if the code cannot work<br />with TMS570LC4357 as is then priority to invest time for rewrite<br />into shape which is potentionally acceptable for OpenOCD mainline<br />is even more important. As for TMS570LS3137, you should be warned<br />that chip revisions older than D have CPU core implementation<br />flaws which can cause problems when code is executed from external<br />SDRAM or SDRAM is used for ETHERNET buffers. I expect that there are<br />no such problems with TMS570LC4357.<br /><br />Best wishes,<br /><br />Pavel<br /><br />PS: as for my availability, I am quite busy by teaching (lectures, seminaries,<br />courses coordination) and Zynq and other targets related work now.<br />I hope to have more time after summer exam period ends in June.<br />I am asked to provide consultation on-site abroad for some<br />company this week when not teaching so expect even more delays<br />in replies now.</p></blockquote><div>Thank you for your reply. I will have the ability to work with a board in a month.</div><div>My target board is TMS570LC43x LaunchPad.</div><div>But I need advice - what can be implemented during the GSoC by me?</div><div>Personally, I am interested in SPI and Serial interfaces, because many</div><div>peripheral work with them. Also, i2c and GPIO are used by me.</div><div>I am interested in Ethernet protocol itself (want to know more how</div><div>it works). And that is strange for me that BBB has IEEE 1588v2 support and</div><div>TMS570 doesn't.</div><div> </div><div> </div><div>---</div><div>Regards,</div><div>Nikolay Komashinskiy</div>