On 11/15/2013 12:39 PM, Olof Kindgren wrote:
2013/11/15 Jonas Bonn <jonas@xxxxxxxxxxxx>
On 11/15/2013 11:22 AM, Geert Uytterhoeven wrote:
This should probably be "altera,de0_nano". We also need to put a version
"terasic,de0_nano"? The board says "Designed and manufactured by Terasic".
Hmm, the sticker on the box says "Altera DE0-Nano".
Good question...
terasic makes more sense than Altera. Altera just provides one of the
components on the board
OK, terasic is probably better then.
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.
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.
/Jonas
//Olof
--
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
