[...] > >>>> Version number needed. OpenCores wanted "projectname-rtlsvn###" where > >>>> ### > >>>> is the SVN commit number of the RTL directory in the project's source > >>>> repository. > >>>> > >>> > >>> That's gonna need some information diving, as Stefan's orpsoc git > >>> repositories > >>> only contains references to orpsocv2 git-svn-ids, not the svn ids of > >>> the original > >>> component repositories. > >>> > >> > >> Stefan? Where's the "official" home of these cores nowadays? Have they > >> been modified since they were copied from OpenCores into orpsocv2? > >> > >> > > Most cores are fetched directly from OpenCores SVN. Out of these, some are > > patched on the fly by ORPSoC before they are being built. Most of the new > > cores are only available on github > > The version number is important in order to ensure _driver_ > compatibility. As long as the patches don't make changes that requires > changes to the Linux driver then it's OK to just put the SVN version > number on them. If incompatible changes are being made, then we really > need to find a "home" for these cores so that we can manage their > version numbers in some way. On this front, I note the CPU node has: compatible = "opencores,or1200-rtlsvn481"; Should this not be something like: compatible = "opencores,or1200-rtlsvn481", "opencores,or1200"; That way falling back to an always known compatible string is easier. > > > > > More generally, can Linux use out-of-tree DTS files in an easy way? It's > > handy to have them in the kernel, but the best fit might actually be to put > > them in the corresponding orpsocv3 system directory. That would also make > > it easier to have separate device trees for differently configured FPGAs > > (they are reprogrammable after all). > > Yes, the DTS files don't really belong in the kernel tree at all. They > belong "near the hardware". For these FPGA projects it definitely makes > sense to keep (or automatically generate) the DTS files in the RTL build > system, i.e. orpsoc. > > We generally build the DTB into the kernel image itself, but that's not > really necessary. You just need to get the DTB into memory and pass the > kernel a pointer to it. If you can find some way to build the DTB into > the FPGA image (block RAM?) then you've got a self-describing HW image: > have the OpenRISC core initialize itself with r3 containing the > address of the DTB and jump to the kernel entry point (reset vector) and > everything should just work. If you put device tree logic into newlib > as well then you can use this HW description for (other) bare metal > apps, as well. > > The device tree compiler is in the Linux kernel tree... but it's usable > outside of the Linux build system, as well. You'll find the binary in > script/dtc/dtc in the kernel tree... run it with --help to get an idea > of how it's used. It really isn't supposed to have anything to do with > Linux at all; it's a generic tool for a generic HW description. It's worth noting the dtc is managed outside of the kernel [1] and periodically new features are pulled in. It's available on it's own, and several distributions package it. As long as the bindings you are using are not in flux, then it's entirely possible to use an out-of-tree dts. Thanks, Mark. [1] http://git.jdl.com/gitweb/?p=dtc.git;a=summary -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
