TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

[Gedare Bloom]

On Wed, Apr 1, 2015 at 7:01 AM, Pavel Pisa <pisa at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel