TMS570 headers ready for review

[Gedare Bloom]

On Fri, Jun 5, 2015 at 3:01 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Gedare,
>
> thanks for response.
>
> On Friday 05 of June 2015 18:18:15 Gedare Bloom wrote:
>> On Tue, Jun 2, 2015 at 9:39 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
>> > Please, look on the files and express your opinion.
>> > The new temporary top level header files is tms5702.h.
>> > It should replace tms570.h.
>>
>> I took a glance at some, I didn't see anything overtly bad, although
>> the generated license is (1) interleaved with excess newlines
>
> That is already corrected in the script.
>
>> and (2) possibly spurious to apply on automatically generated content.
>> The script he wrote should specify itself what the license is on generated
>> files. I'd recommend something that is as permissive as possible when
>> dealing with generated files.
>
> The license is not part of the script, it is provided as template
> so everybody who contributes can add his/her name there.
>
> I support to provide some license in the headers because
> if there is no license then users have no guarantee that
> would not be sued. At least in our country code without
> writtent premission or copyright can be considered
> as fully owned by author. We have switched to two clause BSD,
> which is really permissive license after last discussion.
> I would even prefer that over RTEMS specific one because it
> allows to use header files even in other projects.
> I.e. U-boot for TMS570 would be great even that I do not
> expect to find resources for that.
>

Good, perhaps tms570 can be a next target for umon after this GSoC's
effort with beagleboard.

> Last but not least, Premysl Houdek has spent considerable time
> on that work so he deserves some attribution in my opinion.
>
Certainly! I don't mind that the author notice and license appears, I
just meant that it should be appropriate to the fact the code is
generated automatically, and I'm happy to see 2-BSD used.

>> I'll be curious to see what tms570 users think of the generated headers.
>>
>> > As for the header files organization, we propose to
>> > move peripherals registers header files to the
>> > subdirectory of BSP include path. But because Texas Instruments
>> > IP blocks can appear even on slightly modified chips we
>> > do not propose tms570 name. Our idea is to use "tmsreg" name
>> > and use peripherals headers file names in lowercase form.
>> > The files would be generally included from code through
>> > "tms570.h".
>>
>> I'm fine with the more generic use of names, although I might prefer
>> separation of tms_reg. We also have some generic BSPs that span
>> multiple boards, and I think we prefer something like generic_tms_...
>> now, e.g. generic_or1k was recently added. Older generic code used
>> something more like gen5200. If the IP blocks may be unrelated to the
>> TMS line however, it might be sensible to have something more like
>> generic_ti_...
>>
>> However, until the code is actually shared by multiple BSPs, I might
>> prefer to see it kept local to the tms570.
>
> Yes I agree to keep them local for now but moving to include subdirs
> ensures that they do not mix with the real programmers written BSP
> files. As for the name we could use something like ti_hercules.
> In the fact we should use the gen_ti_hercules for BSP if we
> expect to extend it in future for RM48 and RM57. Ti tools seems
> to put generic stuff of CCS under "Hercules" name so there is some
> hope that they keep IPs from name clashing in that family.
> We have now RM48 boards because paying industry partner wants
> or Matlab/Simulink for both TMS570 and RM48 now. But that project
> is based on Ti tools unfortunately.
>
Oh, yes, a subdir to encapsulate all of them would be good, especially
with their rather simple names. Using ti_hercules should be fine.

>> > Do you agree with proposal?
>> > Have you some more ideas?
>> >
>> > The adjustment of actual BSP sources for the new header files
>> > is minimal. See separate commits. The BSP builds completely
>> > with all examples. We plan more testing in next days.
>>
>> A document of what/how testing was done would be nice, and a
>> relatively good (English) report about the whole process would help I
>> think, if time and energy permit.
>
> I hope that we get to better documentation but the testing is
> critical now. Next task is Ethernet support, it is on the Premek's
> thesis check list to be defended. He has spent to much time on headers
> so he needs to postpone his thesis till end of year to finish that.
> Another important task is to implement correct startup but
> it is above his planned involvement.
>
> As for other thesis, Jan Dolezal's i386 VESA work, he defends
> his thesis over next week and it is written in English so I post
> the link as it is published on the university pages. It can be
> copied to RTEMS as well then.
>
OK sounds good. I read a previous draft of Jan's thesis it seemed nice
at the time! Good luck!

> Best wishes,
>
>                Pavel
>
>