Hello Nikolay and Gedare, On Monday 22 of May 2017 17:03:34 Gedare Bloom wrote: > On Fri, May 19, 2017 at 12:19 PM, Nikolay Komashinskiy > > <nikolay.komashins...@yandex.ru> wrote: > > Hello, > > > > I've started to investigate how to launch RTEMS on top of the TMS570LC43x > > processor and it seems that some additional work should be done. > > > > I can't understand to what extent HalCoGen should be used. It seem these > > two processors (TMS570LC43x and TMS570LS3731) differ in their memory > > maps, in caches (LC43x has it).
yes, I have warned that differences are significant in the past and that if SPI and I2C is not developed on TMS570LS3137 that there is necessary porting to TMS570LC43x. On the other hand, TMS570LC43x is really perspective RTEMS target. Actual peripherals should be be compatible. The peripherals differences (except system and PLL/clock controllion ones) should be only in the direction that TMS570LC43x can have some additional bits. There is significant difference in the pin multiplexer but that should be covered by the code already included in RTEMS. It should support both concepts. On the other hand, it is possible to start from the point where low level initialization is done by "loader"/stub application and RTEMS is compiled without HW init or RTEMS start with HalCoGen generated init. I expect that in such setup only minor adjustment to VIM and peripheral base addresses should enable to run TMS570 BSP on the TMS570LC43x target with serial output. > Yes we need to make the determination of how to use HalCoGen. I'm not > sure if I prefer to include HalCoGen generated code in the git > repository, or just to document how an end user should add the > HalCoGen files themselves. I think I prefer to include the generated > files, since it is then easier to quality control. > > > Also, LC43X has only MibSPI which is extended version of SPI. It should not be a problem, TMS570LS3137 has MibSPI chanel as well. > Does this mean the driver framework we have in cpukit/dev/spi cannot > be used? In this case the SPI driver will have to be developed from > scratch as part of the BSP. I need to recheck, but I think that SPIs are the very similar to AM3/4/5 ones so at least BSD and Linux drivers can be used for inspiration. It should not be a problem to fit all this to Linux like API. > > Also, these boards have a bit different Vector Interrupt Managers > > (different number of interrupts). > > > > Could you explain what should be done in order to get a working RTEMS > > port on top of the board? > > First get the console to work. Console + one context switch = hello > world. So the first step is to get hello world to work properly. The steps to do and confirm by feedback: * use RTEMS Source Builder to prepare toolchain (GCC etc) for mainline master RTEMS build * build TMS570 BSP for example by RSB to test toolchain but I suggest to not continue this way further, use direct build from GIT for next steps * prepare your GitHub personal fork of RTEMS https://github.com/RTEMS/rtems learn how to build BSP from it, I have set of build directories with different configuration side-by GIT sources directory to can rebuild easily RTEMS after modifications for more target without full rebuild. Lear how "bootstrap -c", "bootstrap" and "bootstrap -p" works when you do more substantial changes * grant me (GitHub "ppisa") write access to your repo to simplify some corrections and communication. I can pus some experimental code from my repo there * check that critical peripherals definition matches register description in the TMS570LC43xx manual https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/include/ti_herc Start with reg_sci.h, reg_spi.h, reg_i2c.h, reg_gio.h, reg_vim.h which are listed in the priority order. * check peripherals bases/memory map in https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/tms570/include/tms570.h we should add define for TMS570LC43x and decide how to resolve differences. One option is to move map to tms570-regmap-ls3137.h and left tms570.h include the right one according to the selected chip, other option is to conditionalize these entries which are different between versions. I have obtained information from Ti support that they strive to allocate peripherals location and registers such way in the Hercules line, that they generally are only present or missing in the given address range but do not move and latest version registers definition should be usable for all older versions if fields unimplemented on older ones are not used. But it should be checked and there can be exceptions. I would prefer when fields, registers and peripherals missing on LS31 and introduced on LC43 are conditionalized to easily find incompatibility if BSP is build for older chips. Silent write to unimplemented bits and use of unimplemented features is a problem. * if you find differences in c/src/lib/libbsp/arm/tms570/include/ti_herc files and need to adapt them, try to that systematic way. We have generated all these files by scripts and tools "make all.bat", "make_header.py" etc. found in "headers/python" directories https://github.com/AoLaD/rtems-tms570-utils clone the tools repository and try to adapt files in the JSON form if you need to add one or two fields https://github.com/AoLaD/rtems-tms570-utils/tree/master/headers/prepared_files if there is more differences then the mechanism to run comparison automatically is required. Our registers descriptions files has been obtained hard way by parsing PDFs due to unclear licences status at that days. Files generated by HalCoGen are correctly licensed now. On the other hand I think that files generated from our tools are following better form used by RTEMS (reference is mainly other modern RTEMS ports started or updated by Sebastian Huber). HalCoGen headers quite often lacks definition of masks for peripherals fields etc. The has been worse than what we have for sure in the past and they often differ in registers names and fields names for same peripheral between different family members. At least that has been situation one or two years ago. May it be that it has been improved since then. Anyway, I consider as optimal solution to use HalCoGen or CCS debugger XML definitions of registers and their fields as the source to generate Hercules family wide well matching header files for RTEMS. I plan to contact/speak with Ti representatives I have communicated in the past and check if they support and confirm that we can use this approach. * you should to check startup code stub at https://github.com/hornmich/tms570ls3137-hdk-sdram try to use CCS to populate simple application which setups as much as possible peripherals on your board then prints something to serial port and waits in the infinite loop. Try to use GCC option for the code generation. But even application compiled by Ti compiler counts when runs well on your target. It has to be without operating system and interrupts enabled. Prepare repo with this application. It should be easy copy required files to the RTEMS and use it in that HalCoGen assisted mode to run simple shell demo. Use your GSoC project Wiki page to maintain some TODO list and sumarise your achievements and problems https://devel.rtems.org/wiki/GSoC/2017/TMS570_BSP_improvements It may be possible Trac issue tracking system to organize and prioritize work. But how and under which categories should such points fall should be discussed with Gedare and others. Best wishes, Pavel Pisa _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel