TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

[Pavel Pisa]

Hello Gedare,

On Wednesday 01 of April 2015 16:38:05 Gedare Bloom wrote:
> On Wed, Apr 1, 2015 at 7:01 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> > 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.

BSD is OK with me as well. So we can change headers license.

> > 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.

Hmm, the CRC is special beast because it has CRC block and other
block for different chiphers. The question is if manual or algorithmic
simplification would help there in the long term. Actual solution
leads direct 1:1 mapping from manual to the field name. We can
consult back HalCoGen files there and if they have stabilized on
better convention for given peripheral then we can tune naming.

But actual name is

  TMS570 + peripheral name + register name + field name

directly matchin the manual. We look at this again when we
heave all headers generated by the script. I expect that it
could be in one week now.

> > 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.

No it has to be done by human brain. But there are some code
fragments in manual which could be used directly so I think,
that it is doable. We have bring up many systems with zero
or minimum use of third party code at PiKRON for example.

> Keep an eye out for development of RTEMS with micromonitor bootloader.
> This may be a useful tool for generating code in it maybe.

Thanks for pointer.

> 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.

This is to high goal. The actual goal is to have headers for TMS570
and then to implement Ethernet and basic boot up sequence.
But headers generation concept is intended to be more general
or at least to be used as reference for other chips.

Best wishes,

              Pavel