TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

[Pavel Pisa]

Hello Martin,

On Monday 06 of April 2015 20:18:46 Martin Galvan wrote:
> On Wed, Apr 1, 2015 at 7:35 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> > Hello Martin,
>
> Hi, sorry for the late answer.

No problem, I am in overload mode too.

> > the solution is to define simple JSON format which can be even prepared
> > or edited by hand which holds all information. Unfortuantelly,
> > header files are bad for manual editing and according to Joel and
> > Sebastian preferences we need three defines per each field. And I agree
> > that this is reasonable solution to have consistent and standard approach
> > for header files across different chips.
>
> That's debatable. I agree that it would be great to have a consistent
> formatting for register definition headers across al BSPs, though.
> Perhaps we should consider adding a section for these on the style
> guide, and suggesting (but not requiring) using the JSON approach.

I do not propose to move to JSON for more BSPs and even for TMS570,
I do not push to include JSON in RTEMS sources. But this mechanism
is a possible way to go. Premysl Houdek should report more detailed
what effort is really required to prepare data for some peripheral.
But with use of his macros and then Python scripts he informed me
that he can repeat work for one larger peripheral in about two hours.
Which is not so bad.

> Therefore you conclude I'm right :)

What is the right and wrong is not so important there.
Important is what are the alternatives.

> > Python script is for cleaning generated JSONs and then for
> > generating final header files from these JSONs. But even writting
> > JSONs by hand is simpler than writing headers and JSONs can be easily
> > read for check, debugging and other support. Header files are bad format
> > for that and if use overlay structures then their manual writing
> > from offsets is quite error prone.
>
> Again, that's debatable. We'd have to make extra sure that the Python
> script works perfectly, though, as any bugs will spread to future
> BSPs.

It is less work to correct script than to rewrite hundreds of macros.
But yes, it is additional complexity and place for errors. But for example
comparison of C register overlay structure with manual when header file
is manually written is quite tedious as well. One option is to build code
which computes offsetof for each field and prints it (if you can run
such code on real target) or use trick to make symbol from each
definition and use NM to get offsets and compare them with manual.
I have done something like that to find problems in other target definitions
and it is not fun. Nor computation of reserved arrays and fields
to skip some offsets when you prepare header. I inclined to not use
overlay structures at all and use definition of registers offsets
for this reason. But structures have some advantages - for example
during debugging and code is usually more readable.

So it is all questionable.

> >> The same goes for generating the boot/initialization code using the
> >> script approach. I don't know if such a thing is even possible; but
> >> I'm sure it'll be quite complex. And we still don't know for certain
> >> how reliable this whole approach is.
> >
> > No, boot code has to be written from scratch but with help of manual
> > and HalCoGen generated code as algorithms reference. But it is not
> > so large amount of code at the end. But it is quite complex.
> > As for FlexRay and other peripherals support, which we have supported,
> > these does not use so much of HalCoGen code. Main work is in the drivers
> > logic which is not helped by HalCoGen so much.
>
> Understood.
>
> >> And then there's the timing issue. Given how much effort it has taken
> >> to get to this point, I don't think it's worth to invest even more
> >> time trying to follow the same approach for init code. You mentioned 8
> >> months as a cap; there's got to be a faster way to fix this.
> >
> > The project has not been so actively worked on. Premysl Houdek
> > has some other duties and subjects etc.
>
> I understand that. Unfortunately we need to get the full BSP on the
> mainline as soon as possible. Like I said before, we're more than
> willing to work on the init code ourselves.

I understand.

> > Please, try to negotiate some permissive license which allows
> > headers inclusion and or try to negotiate machine processing and
> > use of HalCoGen generated headers copy (and better even generated
> > sources) in GPL licensed project.
> >
> > I have tried and failed. And we have been quite unhappy and aware
> > of amount of additional work caused by that. I have checked how HalCoGen
> > XML MCU description files looks like and it would be possible to generate
> > header files from them directly without use of the HalCoGen tool.
> > But even that last resort solution has been declared as not suggested
> > and that it would not be blessed by Ti's lawyers department.
> > Ti support people said, that mechanism and licenses are decided (may it
> > be even negotiated with tools vendors) at a time when MCU is released and
> > the changing of license is highly problematic even for Ti after that
> > point. But you can be more sucesfull if you declare budget
> > and projected production quantities.
>
> I'm not saying we should include the Halcogen code directly. I'm
> saying we could instead refactor it, trimming all the unnecesary bits
> such as user hooks and leaving only the bare minimum to get the board
> up and running. It's almost the same as writing the init code by hand
> reading the manual, except it's easier on the developer because he
> doesn't have to figure out everything by himself.

This depends on lawyers what is and what is not copyright breach.
And remember that SCO versus IBM Linux kernel case has been based
on use of same numbers for IOCTLs as has been found AT&T code because
Linus used GLIBC which supported original Unixes and did not changed
the numbers. On this and may it be another similar think and that
case, even that once won by open side, is still possible to recruit
as some rumours about SCO remains say. The SCO remains
are traded and reuse to frighten others and it is only value
of that company.

So I would be carefull there and case and licenses should be checked
by Joel or some OAR lawyer before copyrightable chunk size inclusion
if there is not at least e-mail from Ti that they are OK with it.

So I push forward only things where I hope to be far on safe side.

Premysl Houdek has pushed the work forward by significant
leap from my announce. So I hope that we are back on right track.
But time is enemy and I cannot spent much time on this
in following weeks. I hope he would have final cleaned
JSONs and headers ready soon.

Best wishes,

             Pavel