On Fri, Jun 5, 2015 at 3:01 PM, Pavel Pisa <[email protected]> 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 <[email protected]> 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 > > _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
