On Wed, Apr 1, 2015 at 7:01 AM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote: > Hello all, > > I would like to inform you that Premysl Houdek is near to finishing > preparation of complete registers header files for TMS570LS3137. > The register and fields definition are interactively retrieved > with help of some macro from MCU PDF manual files. This is a great effort
> We decided to store retrieved data in JSON format. > > The raw files are available in rtems-tms570-utils repository > temporary branch > > https://github.com/AoLaD/rtems-tms570-utils/tree/Headers/headers/raw_files > > There are examples of the final JSON files after check/review > for completeness. I.e. for CRC module > > > https://github.com/AoLaD/rtems-tms570-utils/blob/Headers/headers/prepared_files/CRC.json > > Then there is a Python script which generates RTEMS style > headerfiles. Example > > > https://github.com/AoLaD/rtems-tms570-utils/blob/Headers/headers/headers/CRC.h > For headers/code that is automatically generated, I'd like to see a very permissive license applied to the tool output. Slapping an RTEMS License on it is ok, but not ideal to me. I guess we should just ensure the license on the Python script is suitable for use in generating usably-licensed code. I don't know what licensing models exist for this. > The single bit fields are generated as > > #define TMS570_CRC_CRC_INTR_CH2_TIMEOUTENR BSP_FLD32(12) > > The multibit fields should be generated as > > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1(val) BSP_FLD32(val,0, 19) > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1_GET(reg) > BSP_FLD32GET(reg,0, 19) > #define TMS570_CRC_CRC_PCOUNT_REG1_CRC_PAT_COUNT1_SET(reg,val) > BSP_FLD32SET(reg, val,0, 19) > This seems a little verbose. I guess the automatic definitions may be hard to generate, but CRC 3 times in the def name is a lot. > There is now mistake that GET is used once instead of SET in this example. > But that will be corrected. > > It would be great amount of work to prepare complete initialization > sequence from scratch to not touch problematically licensed HalCoGen > files. But when format of header files is agreed upon it is doable. > This is an interesting direction to go. The idea of generating init code (and bootstrap!) from documentation is compelling. > So generally, what is your opinion about the format? > (may be that tools and approach can be reused for other chips as well) > > We plan to shake-up actual RTEMS TMS570 serial port and timers > support to use proposed headers format. Then we start on HalCoGen-free > boot-up process work. So I hope we can have complete self-contained > RTEMS support mainlined one day. > Keep an eye out for development of RTEMS with micromonitor bootloader. This may be a useful tool for generating code in it maybe. > The first step is to finish headers and replace initial sparse > ones in RTEMS mainline by new set. I expect that we include only > header files in RTEMS and JSONs stay in utils repo. But we are open > to other suggestions as well. > > To Martin Galvan: What is your opinion? Would you join the work in > this direction? > > We have no contract for the work so I cannot promise any timing. > Premysl Houdek should to finish main part of the work before > his thesis submission. Which can be in two up to max eight months. > I think if you can get proof-of-concept for generating bootstrap code from documentation, this could be compelling for some users out there to give money to produce non-GPL bootloaders for other boards. Not that I know of any off-hand. > Best wishes, > > Pavel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
