Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sat, Nov 9, 2013 at 2:37 PM, Geert Uytterhoeven wrote:
> Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
> Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
> support chips and I/O.
>
> The DTS was derived from published versions by Kevin Mehall and Marek
> Czerski.
>
> Signed-off-by: Geert Uytterhoeven
> Cc: Kevin Mehall
> Cc: Marek Czerski
> ---
> Notable changes:
> - Change flash0 to spansion,s25sl064p, due to kernel message
> m25p80 spi32766.0: found s25sl064p, expected m25p10
> - Use reg-shift instead of regstep for i2c0, due to kernel message
> ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
>
> arch/openrisc/boot/dts/de0_nano.dts | 158
> ++
> arch/openrisc/configs/de0_nano_defconfig | 86
> 2 files changed, 244 insertions(+)
> create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
> create mode 100644 arch/openrisc/configs/de0_nano_defconfig
>
> diff --git a/arch/openrisc/boot/dts/de0_nano.dts
> b/arch/openrisc/boot/dts/de0_nano.dts
> new file mode 100644
> index ..42f91b5184d9
> --- /dev/null
> +++ b/arch/openrisc/boot/dts/de0_nano.dts
> @@ -0,0 +1,158 @@
> +/dts-v1/;
> +/ {
> + compatible = "opencores,de0_nano";
This string needs to be documented.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <>;
> +
> + chosen {
> + bootargs = "console=uart,mmio,0x9000,115200";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x 0x0200>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "opencores,or1200-rtlsvn481";
> + reg = <0>;
> + clock-frequency = <5000>;
> + };
> + };
> +
> + /*
> +* OR1K PIC is built into CPU and accessed via special purpose
> +* registers. It is not addressable and, hence, has no 'reg'
> +* property.
> +*/
> + pic: pic {
> + compatible = "opencores,or1k-pic";
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> +
> + serial0: serial@9000 {
These memory mapped devices should be under a bus node of some sort.
Typically a "simple-bus" node.
> + compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
This needs to be documented. Same comment applies to all compatible strings.
> + reg = <0x9000 0x100>;
> + interrupts = <2>;
> + clock-frequency = <5000>;
> + };
> +
> + i2c0: ocores@a000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "opencores,i2c-ocores";
> + reg = <0xa000 0x8>;
> + interrupts = <10>;
> + clock-frequency = <5000>;
> +
> + reg-shift = <0>;/* 8 bit registers */
> + reg-io-width = <1>; /* 8 bit read/write */
> +
> + adxl34x@1d {
> + compatible = "adxl34x";
> + reg = <0x1d>;
> + interrupts = <26>;
> + };
> + eeprom@50 {
> + compatible = "at24,24c02";
> + reg = <0x50>;
> + pagesize = <8>;
> + };
> + };
> +
> + spi0: spi0@b000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "opencores,spi-simple";
Is this different than "opencores,tiny-spi-rtlsvn2"? Is "simple"
something I can correlate to a specific version of h/w?
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sat, Nov 9, 2013 at 2:37 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Kevin Mehall cont...@kevinmehall.net
Cc: Marek Czerski ma.czer...@gmail.com
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158
++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = opencores,de0_nano;
This string needs to be documented.
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = pic;
+
+ chosen {
+ bootargs = console=uart,mmio,0x9000,115200;
+ };
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x 0x0200;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ cpu@0 {
+ compatible = opencores,or1200-rtlsvn481;
+ reg = 0;
+ clock-frequency = 5000;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = opencores,or1k-pic;
+ #interrupt-cells = 1;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
These memory mapped devices should be under a bus node of some sort.
Typically a simple-bus node.
+ compatible = opencores,uart16550-rtlsvn105, ns16550a;
This needs to be documented. Same comment applies to all compatible strings.
+ reg = 0x9000 0x100;
+ interrupts = 2;
+ clock-frequency = 5000;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,i2c-ocores;
+ reg = 0xa000 0x8;
+ interrupts = 10;
+ clock-frequency = 5000;
+
+ reg-shift = 0;/* 8 bit registers */
+ reg-io-width = 1; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = adxl34x;
+ reg = 0x1d;
+ interrupts = 26;
+ };
+ eeprom@50 {
+ compatible = at24,24c02;
+ reg = 0x50;
+ pagesize = 8;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,spi-simple;
Is this different than opencores,tiny-spi-rtlsvn2? Is simple
something I can correlate to a specific version of h/w?
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Olof,
I think this discussion is veering away from what's relevant for the
linux-kernel and devicetree lists and did consider dropping them at this
point... but let's leave them in the discussion a bit longer in case
there's some sage guidance to be found there on the topic of doing sane
versioning of open source hardware.
On 11/16/13 12:01, Olof Kindgren wrote:
2013/11/16 Stefan Kristiansson
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
+
+i2c0: ocores@a000 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "opencores,i2c-ocores";
Version number needed. OpenCores wanted "projectname-rtlsvn###"
where ### is the SVN commit number of the RTL directory in the
project's source repository.
That will also require a change to the driver.
The drivers in question aren't upstream so it's not a big deal. Making a
change to get sane revisioning would be worth it anyway.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
The DTS version tells the driver what feature set it can expect to find
in the HW core and thus how to go about driving it. Normally, the core
won't change features much, but if you add something new you'd want the
driver to see a new 'compatible' tag so that it knows which features it
can/should enable. New features will always entail driver changes; and
a driver can always be compatible with both the old and new HW versions
by just enabling the feature set appropriate to the HW in question.
Stefan
___
Linux mailing list
li...@lists.openrisc.net
http://lists.openrisc.net/listinfo/linux
I agree. I don't like doing versioning with revision numbers. It's too
closely tied to the currently used VCS. The problem is that no one has
bothered to do proper releases of the cores for the last ten years or
so.
But since we are talking about a relatively small amount of cores
here, I think it could be worth to take a quick glance to see if the
latest SVN version is compatible with the latest tagged release. I
would suspect that is the case for the majority of the cores and the
we can just use the latest tag as version. For the other cores we
could
1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
2. Take over maintainership/fork and just release what's in the trunk
(taking over maintenance is preferrable here to avoid more repo
confusion)
3. Use SVN revisions
option 2 would be my preferred choice here, given that we get someone
to do the actual work. I could probably help out with a few of the
cores
My suggestion:
i) Move the primary source of these cores to git (doesn't matter
where... github is fine)
ii) Use a shortened git commit ID (6 chars) as the version number
Why?
i) The commit ID is independent of the repository; whether the repo is
opencores, github, or olof's computer, the commit ID is constant
ii) Tag names are arbitrary labels; they don't contain any more
information than the commit ID
iii) The commit ID, being a hash of the source and repository history
itself, contains information that makes it effectively impossible for
someone to attach the same label to an incompatible core
iv) I think everyone actively working on these cores today are doing so
via git already... via orpsocv2/3, presumably
NB: you might do named releases of a core, from versions 1.2 to 2.5, but
if the underlying feature set remains the same and the same driver
applies then the DTS 'compatible' tag would remain constant across all
these releases. This means that the HW feature set is decoupled from
the arbitrary version numbers that people like to use when doing releases.
Jonas, you said that opencores wanted projectname-svnversion. Do you
know where that comes from? My proposal here would conflict with that
It came out of a private conversion I had with Marcus Erlandsson (who
spoke for OpenCores at the time). The OpenRISC project hadn't really
moved on to git back then (as it has today) so it was the best we could
come up with.
/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Olof,
I think this discussion is veering away from what's relevant for the
linux-kernel and devicetree lists and did consider dropping them at this
point... but let's leave them in the discussion a bit longer in case
there's some sage guidance to be found there on the topic of doing sane
versioning of open source hardware.
On 11/16/13 12:01, Olof Kindgren wrote:
2013/11/16 Stefan Kristiansson stefan.kristians...@saunalahti.fi
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
+
+i2c0: ocores@a000 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = opencores,i2c-ocores;
Version number needed. OpenCores wanted projectname-rtlsvn###
where ### is the SVN commit number of the RTL directory in the
project's source repository.
That will also require a change to the driver.
The drivers in question aren't upstream so it's not a big deal. Making a
change to get sane revisioning would be worth it anyway.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
The DTS version tells the driver what feature set it can expect to find
in the HW core and thus how to go about driving it. Normally, the core
won't change features much, but if you add something new you'd want the
driver to see a new 'compatible' tag so that it knows which features it
can/should enable. New features will always entail driver changes; and
a driver can always be compatible with both the old and new HW versions
by just enabling the feature set appropriate to the HW in question.
Stefan
___
Linux mailing list
li...@lists.openrisc.net
http://lists.openrisc.net/listinfo/linux
I agree. I don't like doing versioning with revision numbers. It's too
closely tied to the currently used VCS. The problem is that no one has
bothered to do proper releases of the cores for the last ten years or
so.
But since we are talking about a relatively small amount of cores
here, I think it could be worth to take a quick glance to see if the
latest SVN version is compatible with the latest tagged release. I
would suspect that is the case for the majority of the cores and the
we can just use the latest tag as version. For the other cores we
could
1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
2. Take over maintainership/fork and just release what's in the trunk
(taking over maintenance is preferrable here to avoid more repo
confusion)
3. Use SVN revisions
option 2 would be my preferred choice here, given that we get someone
to do the actual work. I could probably help out with a few of the
cores
My suggestion:
i) Move the primary source of these cores to git (doesn't matter
where... github is fine)
ii) Use a shortened git commit ID (6 chars) as the version number
Why?
i) The commit ID is independent of the repository; whether the repo is
opencores, github, or olof's computer, the commit ID is constant
ii) Tag names are arbitrary labels; they don't contain any more
information than the commit ID
iii) The commit ID, being a hash of the source and repository history
itself, contains information that makes it effectively impossible for
someone to attach the same label to an incompatible core
iv) I think everyone actively working on these cores today are doing so
via git already... via orpsocv2/3, presumably
NB: you might do named releases of a core, from versions 1.2 to 2.5, but
if the underlying feature set remains the same and the same driver
applies then the DTS 'compatible' tag would remain constant across all
these releases. This means that the HW feature set is decoupled from
the arbitrary version numbers that people like to use when doing releases.
Jonas, you said that opencores wanted projectname-svnversion. Do you
know where that comes from? My proposal here would conflict with that
It came out of a private conversion I had with Marcus Erlandsson (who
spoke for OpenCores at the time). The OpenRISC project hadn't really
moved on to git back then (as it has today) so it was the best we could
come up with.
/Jonas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
2013/11/16 Stefan Kristiansson
>
> On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> > >+
> > >+i2c0: ocores@a000 {
> > >+#address-cells = <1>;
> > >+#size-cells = <0>;
> > >+compatible = "opencores,i2c-ocores";
> >
> > Version number needed. OpenCores wanted "projectname-rtlsvn###"
> > where ### is the SVN commit number of the RTL directory in the
> > project's source repository.
> >
>
> That will also require a change to the driver.
>
> Using svn commit ids as version info seems a bit too fine grained to me,
> but if that's what's agreed on, then it should be the commit id from the
> projects official repository at opencores.org I think.
>
> Stefan
> ___
> Linux mailing list
> li...@lists.openrisc.net
> http://lists.openrisc.net/listinfo/linux
I agree. I don't like doing versioning with revision numbers. It's too
closely tied to the currently used VCS. The problem is that no one has
bothered to do proper releases of the cores for the last ten years or
so.
But since we are talking about a relatively small amount of cores
here, I think it could be worth to take a quick glance to see if the
latest SVN version is compatible with the latest tagged release. I
would suspect that is the case for the majority of the cores and the
we can just use the latest tag as version. For the other cores we
could
1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
2. Take over maintainership/fork and just release what's in the trunk
(taking over maintenance is preferrable here to avoid more repo
confusion)
3. Use SVN revisions
option 2 would be my preferred choice here, given that we get someone
to do the actual work. I could probably help out with a few of the
cores
Jonas, you said that opencores wanted projectname-svnversion. Do you
know where that comes from? My proposal here would conflict with that
//Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> >+
> >+i2c0: ocores@a000 {
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+compatible = "opencores,i2c-ocores";
>
> Version number needed. OpenCores wanted "projectname-rtlsvn###"
> where ### is the SVN commit number of the RTL directory in the
> project's source repository.
>
That will also require a change to the driver.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
+
+i2c0: ocores@a000 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = opencores,i2c-ocores;
Version number needed. OpenCores wanted projectname-rtlsvn###
where ### is the SVN commit number of the RTL directory in the
project's source repository.
That will also require a change to the driver.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
Stefan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
2013/11/16 Stefan Kristiansson stefan.kristians...@saunalahti.fi
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
+
+i2c0: ocores@a000 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = opencores,i2c-ocores;
Version number needed. OpenCores wanted projectname-rtlsvn###
where ### is the SVN commit number of the RTL directory in the
project's source repository.
That will also require a change to the driver.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
Stefan
___
Linux mailing list
li...@lists.openrisc.net
http://lists.openrisc.net/listinfo/linux
I agree. I don't like doing versioning with revision numbers. It's too
closely tied to the currently used VCS. The problem is that no one has
bothered to do proper releases of the cores for the last ten years or
so.
But since we are talking about a relatively small amount of cores
here, I think it could be worth to take a quick glance to see if the
latest SVN version is compatible with the latest tagged release. I
would suspect that is the case for the majority of the cores and the
we can just use the latest tag as version. For the other cores we
could
1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
2. Take over maintainership/fork and just release what's in the trunk
(taking over maintenance is preferrable here to avoid more repo
confusion)
3. Use SVN revisions
option 2 would be my preferred choice here, given that we get someone
to do the actual work. I could probably help out with a few of the
cores
Jonas, you said that opencores wanted projectname-svnversion. Do you
know where that comes from? My proposal here would conflict with that
//Olof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
[...] > 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 09:50:18AM +, Jonas Bonn wrote:
[...]
> > + gpio0: gpio@9100 {
> > + compatible = "opencores,jbtrivial";
>
> There's no project called 'jbtrivial' at OpenCores. Should this be
> "linux,jbtrivial" to indicate that this refers to a Linux driver?
I would prefer not. Having driver names in bindings is an antipattern;
drivers should be free to change independently of the hardware or
bindings, and we should be able to create new drivers that handle
existing bindings.
Either a new compatible string should be allcoated, or one of the
generic bindings should be used. While we do have drivers for the
generic cases, the *-generic bindings are treated as a specification
that hardware can meet, and are not intended to change. They are also
there fore independent of Linux.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 11/15/2013 12:39 PM, Olof Kindgren wrote: 2013/11/15 Jonas Bonn 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 12:39 PM, Olof Kindgren wrote:
> 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).
If I'm not mistaken, this is ORPSoC v2?
Yes, it would be nice to have the DTS in ORPSoc itself.
Still, we would need overlays for the devices that are not defined in
ORPSoC, e.g. on-board (and off-board) devices on i2c and spi.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
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... 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? Like I mentioned earlier, I'd like to see this thing disappear altogether and be replaced with gpio-generic. That needs device-tree support and published bindings first. IIRC, you had some preliminary code? I thought I did, but I was mistaken. I don't have anything for gpio-generic. /Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 11:22 AM, Geert Uytterhoeven
wrote:
> The supplied schematics filename is de0-nano-c4-rev-c\(release_cd_rom\).pdf,
> and the drawings mention "Rev C".
> The block diagram on page 2 still says "EPCS16 (16 Mb), but on page 8 it
> mentions "EPCS64", which is what's on my board.
I found the Rev B schematics on the web. It lacks the EPCS drawing
on page 8.
According to
http://forums.parallax.com/showthread.php/132578-Getting-started-with-FPGAs/page7
there are also versions with a 64 Mbit Altera EPCS64.
So my guess is:
Rev A: EPCS16
Rev B: Altera EPCS64
Rev C: Spansian EPCS64
Unless Andrew and I have Rev Fs, as there's no "C" on our boards.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Jonas,
On Fri, Nov 15, 2013 at 10:50 AM, Jonas Bonn wrote:
>> +++ b/arch/openrisc/boot/dts/de0_nano.dts
>> @@ -0,0 +1,158 @@
>> +/dts-v1/;
>> +/ {
>> + compatible = "opencores,de0_nano";
>
> 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".
> number of some kind on this thing. How are the de0_nano boards versioned?
That's a good question...
See also Andrew back's email and my response.
The supplied schematics filename is de0-nano-c4-rev-c\(release_cd_rom\).pdf,
and the drawings mention "Rev C".
The block diagram on page 2 still says "EPCS16 (16 Mb), but on page 8 it
mentions "EPCS64", which is what's on my board.
>> + i2c0: ocores@a000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "opencores,i2c-ocores";
>
>
> 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.
>> + gpio0: gpio@9100 {
>> + compatible = "opencores,jbtrivial";
>
>
> There's no project called 'jbtrivial' at OpenCores. Should this be
> "linux,jbtrivial" to indicate that this refers to a Linux driver?
>
>> + reg = <0x9100 0x2>;
>> + #gpio-cells = <2>;
>> + gpio-controller;
>> + xlnx,data-offset = <0>;
>> + xlnx,tri-offset = <1>;
>> + xlnx,gpio-width = <8>;
>
>
> Yuck... I wrote this driver with a similar driver for a Xilinx part as a
> starting point. Apparently I left the Xilenx (xlnx) tags in there for the
> device properties. We can't really have it like this, though.
>
> Like I mentioned earlier, I'd like to see this thing disappear altogether
> and be replaced with gpio-generic.
That needs device-tree support and published bindings first. IIRC, you
had some preliminary code?
Thanks for review!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 15 November 2013 10:10, Geert Uytterhoeven wrote: > On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back wrote: >> P012060013 >> 94V-0 >> HL9-VO > > Same here. > >> 1227 F > > Mine says "1321 F" > > Do you have the 8 MiB Spansion FL064PIF? Yes. Although it looks as though someone has drawn over the first "F" with black pen, so it sort of reads "L064PIF". Best, Andrew -- Andrew Back Principal, AB Open Ltd http://abopen.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back wrote:
> P012060013
> 94V-0
> HL9-VO
Same here.
> 1227 F
Mine says "1321 F"
Do you have the 8 MiB Spansion FL064PIF?
> Plus a barcode sticker which I assume is the S/N.
Idem ditto. And the last 4 digits don't match the sticker on the box. Hmm...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 15 November 2013 09:52, Jonas Bonn wrote: > On 11/10/2013 06:51 AM, Stefan Kristiansson wrote: >> >> On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: >>> >>> Notable changes: >>>- Change flash0 to spansion,s25sl064p, due to kernel message >>> m25p80 spi32766.0: found s25sl064p, expected m25p10 >> >> >> This is due to Altera changing the EPCS chip on newer revisions >> of that board, older versions are "relabeled" m25p10 and >> newer once s25sl064p. >> The change is fine though, you have to pick one. > > > Actually, you want two DTS's: one for each version of the board with a > 'compatible' property to help select the right one. What do the revision > numbers for these boards look like? The bottom of my board has the following text: P012060013 94V-0 HL9-VO 1227 F Plus a barcode sticker which I assume is the S/N. Best, Andrew -- Principal, AB Open Ltd http://abopen.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 11/10/2013 06:51 AM, Stefan Kristiansson wrote: On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: Notable changes: - Change flash0 to spansion,s25sl064p, due to kernel message m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are "relabeled" m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Actually, you want two DTS's: one for each version of the board with a 'compatible' property to help select the right one. What do the revision numbers for these boards look like? /Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Geert,
I'll pull this into my OpenRISC tree now as-is, but there's a couple of
things that need sorting out before this can be upstreamed... see below.
Thanks,
Jonas
On 11/09/2013 09:37 PM, Geert Uytterhoeven wrote:
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven
Cc: Kevin Mehall
Cc: Marek Czerski
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158 ++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = "opencores,de0_nano";
This should probably be "altera,de0_nano". We also need to put a
version number of some kind on this thing. How are the de0_nano boards
versioned?
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ chosen {
+ bootargs = "console=uart,mmio,0x9000,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x0200>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "opencores,or1200-rtlsvn481";
+ reg = <0>;
+ clock-frequency = <5000>;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = "opencores,or1k-pic";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+ reg = <0x9000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <5000>;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,i2c-ocores";
Version number needed. OpenCores wanted "projectname-rtlsvn###" where
### is the SVN commit number of the RTL directory in the project's
source repository.
+ reg = <0xa000 0x8>;
+ interrupts = <10>;
+ clock-frequency = <5000>;
+
+ reg-shift = <0>; /* 8 bit registers */
+ reg-io-width = <1>; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom@50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
Version number.
+ reg = <0xb000 0x5>;
+
+ flash0: mtd@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl064p";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "FPGA image";
+ reg = <0x 0x000b>;
+ read-only;
+ };
+ partition@b {
+ label = "bootloader";
+ reg = <0x000b 0x0005>;
+ read-only;
+ };
+ partition@10 {
+ label = "free space";
+ reg = <0x0010 0x0070>;
+ };
+ };
+ };
+
+ spi1: spi1@b100 {
+ #address-cells = <1>;
+
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Geert,
I'll pull this into my OpenRISC tree now as-is, but there's a couple of
things that need sorting out before this can be upstreamed... see below.
Thanks,
Jonas
On 11/09/2013 09:37 PM, Geert Uytterhoeven wrote:
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Kevin Mehall cont...@kevinmehall.net
Cc: Marek Czerski ma.czer...@gmail.com
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158 ++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = opencores,de0_nano;
This should probably be altera,de0_nano. We also need to put a
version number of some kind on this thing. How are the de0_nano boards
versioned?
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = pic;
+
+ chosen {
+ bootargs = console=uart,mmio,0x9000,115200;
+ };
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x 0x0200;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ cpu@0 {
+ compatible = opencores,or1200-rtlsvn481;
+ reg = 0;
+ clock-frequency = 5000;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = opencores,or1k-pic;
+ #interrupt-cells = 1;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
+ compatible = opencores,uart16550-rtlsvn105, ns16550a;
+ reg = 0x9000 0x100;
+ interrupts = 2;
+ clock-frequency = 5000;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,i2c-ocores;
Version number needed. OpenCores wanted projectname-rtlsvn### where
### is the SVN commit number of the RTL directory in the project's
source repository.
+ reg = 0xa000 0x8;
+ interrupts = 10;
+ clock-frequency = 5000;
+
+ reg-shift = 0; /* 8 bit registers */
+ reg-io-width = 1; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = adxl34x;
+ reg = 0x1d;
+ interrupts = 26;
+ };
+ eeprom@50 {
+ compatible = at24,24c02;
+ reg = 0x50;
+ pagesize = 8;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,spi-simple;
Version number.
+ reg = 0xb000 0x5;
+
+ flash0: mtd@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25sl064p;
+ reg = 0;
+ spi-max-frequency = 4000;
+ m25p,fast-read;
+
+ partition@0 {
+ label = FPGA image;
+ reg = 0x 0x000b;
+ read-only;
+ };
+ partition@b {
+ label = bootloader;
+ reg = 0x000b 0x0005;
+ read-only;
+ };
+ partition@10 {
+ label = free space;
+ reg = 0x0010 0x0070;
+ };
+ };
+ };
+
+ spi1: spi1@b100 {
+ #address-cells = 1;
+ #size-cells = 0;
+
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 11/10/2013 06:51 AM, Stefan Kristiansson wrote: On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: Notable changes: - Change flash0 to spansion,s25sl064p, due to kernel message m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are relabeled m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Actually, you want two DTS's: one for each version of the board with a 'compatible' property to help select the right one. What do the revision numbers for these boards look like? /Jonas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 15 November 2013 09:52, Jonas Bonn jo...@southpole.se wrote: On 11/10/2013 06:51 AM, Stefan Kristiansson wrote: On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: Notable changes: - Change flash0 to spansion,s25sl064p, due to kernel message m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are relabeled m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Actually, you want two DTS's: one for each version of the board with a 'compatible' property to help select the right one. What do the revision numbers for these boards look like? The bottom of my board has the following text: P012060013 94V-0 HL9-VO 1227 F Plus a barcode sticker which I assume is the S/N. Best, Andrew -- Principal, AB Open Ltd http://abopen.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back and...@abopen.com wrote:
P012060013
94V-0
HL9-VO
Same here.
1227 F
Mine says 1321 F
Do you have the 8 MiB Spansion FL064PIF?
Plus a barcode sticker which I assume is the S/N.
Idem ditto. And the last 4 digits don't match the sticker on the box. Hmm...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 15 November 2013 10:10, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back and...@abopen.com wrote: P012060013 94V-0 HL9-VO Same here. 1227 F Mine says 1321 F Do you have the 8 MiB Spansion FL064PIF? Yes. Although it looks as though someone has drawn over the first F with black pen, so it sort of reads L064PIF. Best, Andrew -- Andrew Back Principal, AB Open Ltd http://abopen.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Hi Jonas,
On Fri, Nov 15, 2013 at 10:50 AM, Jonas Bonn jo...@southpole.se wrote:
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = opencores,de0_nano;
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.
number of some kind on this thing. How are the de0_nano boards versioned?
That's a good question...
See also Andrew back's email and my response.
The supplied schematics filename is de0-nano-c4-rev-c\(release_cd_rom\).pdf,
and the drawings mention Rev C.
The block diagram on page 2 still says EPCS16 (16 Mb), but on page 8 it
mentions EPCS64, which is what's on my board.
+ i2c0: ocores@a000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,i2c-ocores;
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.
+ gpio0: gpio@9100 {
+ compatible = opencores,jbtrivial;
There's no project called 'jbtrivial' at OpenCores. Should this be
linux,jbtrivial to indicate that this refers to a Linux driver?
+ reg = 0x9100 0x2;
+ #gpio-cells = 2;
+ gpio-controller;
+ xlnx,data-offset = 0;
+ xlnx,tri-offset = 1;
+ xlnx,gpio-width = 8;
Yuck... I wrote this driver with a similar driver for a Xilinx part as a
starting point. Apparently I left the Xilenx (xlnx) tags in there for the
device properties. We can't really have it like this, though.
Like I mentioned earlier, I'd like to see this thing disappear altogether
and be replaced with gpio-generic.
That needs device-tree support and published bindings first. IIRC, you
had some preliminary code?
Thanks for review!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 11:22 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
The supplied schematics filename is de0-nano-c4-rev-c\(release_cd_rom\).pdf,
and the drawings mention Rev C.
The block diagram on page 2 still says EPCS16 (16 Mb), but on page 8 it
mentions EPCS64, which is what's on my board.
I found the Rev B schematics on the web. It lacks the EPCS drawing
on page 8.
According to
http://forums.parallax.com/showthread.php/132578-Getting-started-with-FPGAs/page7
there are also versions with a 64 Mbit Altera EPCS64.
So my guess is:
Rev A: EPCS16
Rev B: Altera EPCS64
Rev C: Spansian EPCS64
Unless Andrew and I have Rev Fs, as there's no C on our boards.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
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... 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? Like I mentioned earlier, I'd like to see this thing disappear altogether and be replaced with gpio-generic. That needs device-tree support and published bindings first. IIRC, you had some preliminary code? I thought I did, but I was mistaken. I don't have anything for gpio-generic. /Jonas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 12:39 PM, Olof Kindgren olof.kindg...@gmail.com wrote:
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).
If I'm not mistaken, this is ORPSoC v2?
Yes, it would be nice to have the DTS in ORPSoc itself.
Still, we would need overlays for the devices that are not defined in
ORPSoC, e.g. on-board (and off-board) devices on i2c and spi.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On 11/15/2013 12:39 PM, Olof Kindgren wrote: 2013/11/15 Jonas Bonn jo...@southpole.se 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 09:50:18AM +, Jonas Bonn wrote:
[...]
+ gpio0: gpio@9100 {
+ compatible = opencores,jbtrivial;
There's no project called 'jbtrivial' at OpenCores. Should this be
linux,jbtrivial to indicate that this refers to a Linux driver?
I would prefer not. Having driver names in bindings is an antipattern;
drivers should be free to change independently of the hardware or
bindings, and we should be able to create new drivers that handle
existing bindings.
Either a new compatible string should be allcoated, or one of the
generic bindings should be used. While we do have drivers for the
generic cases, the *-generic bindings are treated as a specification
that hardware can meet, and are not intended to change. They are also
there fore independent of Linux.
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
[...] 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sun, Nov 10, 2013 at 6:51 AM, Stefan Kristiansson
wrote:
> On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote:
>> Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
>> Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
>> support chips and I/O.
>>
>> The DTS was derived from published versions by Kevin Mehall and Marek
>> Czerski.
>
> To give credit where credit is due, this was created by:
> Gong Tao
Sorry, I didn't know that. Jonas: please add.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sun, Nov 10, 2013 at 6:51 AM, Stefan Kristiansson
stefan.kristians...@saunalahti.fi wrote:
On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote:
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
To give credit where credit is due, this was created by:
Gong Tao gongtao0...@gmail.com
Sorry, I didn't know that. Jonas: please add.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: > Add a DTS and defconfig for the Terasic DE0-Nano Development and Education > Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with > support chips and I/O. > > The DTS was derived from published versions by Kevin Mehall and Marek > Czerski. To give credit where credit is due, this was created by: Gong Tao > > Signed-off-by: Geert Uytterhoeven > Cc: Kevin Mehall > Cc: Marek Czerski > --- > Notable changes: > - Change flash0 to spansion,s25sl064p, due to kernel message > m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are "relabeled" m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven
Cc: Kevin Mehall
Cc: Marek Czerski
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158 ++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = "opencores,de0_nano";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ chosen {
+ bootargs = "console=uart,mmio,0x9000,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x0200>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "opencores,or1200-rtlsvn481";
+ reg = <0>;
+ clock-frequency = <5000>;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = "opencores,or1k-pic";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+ reg = <0x9000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <5000>;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,i2c-ocores";
+ reg = <0xa000 0x8>;
+ interrupts = <10>;
+ clock-frequency = <5000>;
+
+ reg-shift = <0>;/* 8 bit registers */
+ reg-io-width = <1>; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom@50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb000 0x5>;
+
+ flash0: mtd@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl064p";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "FPGA image";
+ reg = <0x 0x000b>;
+ read-only;
+ };
+ partition@b {
+ label = "bootloader";
+ reg = <0x000b 0x0005>;
+ read-only;
+ };
+ partition@10 {
+ label = "free space";
+ reg = <0x0010 0x0070>;
+ };
+ };
+ };
+
+ spi1: spi1@b100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb100 0x5>;
+
+ adc@0 {
+ compatible = "adcxx,adcxx8s";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ };
+ };
+
+ gpio0: gpio@9100 {
+ compatible = "opencores,jbtrivial";
+ reg = <0x9100 0x2>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ xlnx,data-offset = <0>;
+ xlnx,tri-offset
[PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Add a DTS and defconfig for the Terasic DE0-Nano Development and Education
Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with
support chips and I/O.
The DTS was derived from published versions by Kevin Mehall and Marek
Czerski.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Kevin Mehall cont...@kevinmehall.net
Cc: Marek Czerski ma.czer...@gmail.com
---
Notable changes:
- Change flash0 to spansion,s25sl064p, due to kernel message
m25p80 spi32766.0: found s25sl064p, expected m25p10
- Use reg-shift instead of regstep for i2c0, due to kernel message
ocores-i2c a000.ocores: regstep property deprecated, use reg-shift
arch/openrisc/boot/dts/de0_nano.dts | 158 ++
arch/openrisc/configs/de0_nano_defconfig | 86
2 files changed, 244 insertions(+)
create mode 100644 arch/openrisc/boot/dts/de0_nano.dts
create mode 100644 arch/openrisc/configs/de0_nano_defconfig
diff --git a/arch/openrisc/boot/dts/de0_nano.dts
b/arch/openrisc/boot/dts/de0_nano.dts
new file mode 100644
index ..42f91b5184d9
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0_nano.dts
@@ -0,0 +1,158 @@
+/dts-v1/;
+/ {
+ compatible = opencores,de0_nano;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = pic;
+
+ chosen {
+ bootargs = console=uart,mmio,0x9000,115200;
+ };
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x 0x0200;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ cpu@0 {
+ compatible = opencores,or1200-rtlsvn481;
+ reg = 0;
+ clock-frequency = 5000;
+ };
+ };
+
+ /*
+* OR1K PIC is built into CPU and accessed via special purpose
+* registers. It is not addressable and, hence, has no 'reg'
+* property.
+*/
+ pic: pic {
+ compatible = opencores,or1k-pic;
+ #interrupt-cells = 1;
+ interrupt-controller;
+ };
+
+ serial0: serial@9000 {
+ compatible = opencores,uart16550-rtlsvn105, ns16550a;
+ reg = 0x9000 0x100;
+ interrupts = 2;
+ clock-frequency = 5000;
+ };
+
+ i2c0: ocores@a000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,i2c-ocores;
+ reg = 0xa000 0x8;
+ interrupts = 10;
+ clock-frequency = 5000;
+
+ reg-shift = 0;/* 8 bit registers */
+ reg-io-width = 1; /* 8 bit read/write */
+
+ adxl34x@1d {
+ compatible = adxl34x;
+ reg = 0x1d;
+ interrupts = 26;
+ };
+ eeprom@50 {
+ compatible = at24,24c02;
+ reg = 0x50;
+ pagesize = 8;
+ };
+ };
+
+ spi0: spi0@b000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,spi-simple;
+ reg = 0xb000 0x5;
+
+ flash0: mtd@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25sl064p;
+ reg = 0;
+ spi-max-frequency = 4000;
+ m25p,fast-read;
+
+ partition@0 {
+ label = FPGA image;
+ reg = 0x 0x000b;
+ read-only;
+ };
+ partition@b {
+ label = bootloader;
+ reg = 0x000b 0x0005;
+ read-only;
+ };
+ partition@10 {
+ label = free space;
+ reg = 0x0010 0x0070;
+ };
+ };
+ };
+
+ spi1: spi1@b100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = opencores,spi-simple;
+ reg = 0xb100 0x5;
+
+ adc@0 {
+ compatible = adcxx,adcxx8s;
+ reg = 0;
+ spi-max-frequency = 100;
+ };
+ };
+
+ gpio0: gpio@9100 {
+ compatible = opencores,jbtrivial;
+ reg = 0x9100 0x2;
+ #gpio-cells = 2;
+ gpio-controller;
+ xlnx,data-offset = 0;
+ xlnx,tri-offset = 1;
+ xlnx,gpio-width = 8;
+
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Sat, Nov 09, 2013 at 09:37:31PM +0100, Geert Uytterhoeven wrote: Add a DTS and defconfig for the Terasic DE0-Nano Development and Education Board running ORPSoC. This board contains an Altera Cyclone IV FPGA with support chips and I/O. The DTS was derived from published versions by Kevin Mehall and Marek Czerski. To give credit where credit is due, this was created by: Gong Tao gongtao0...@gmail.com Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Cc: Kevin Mehall cont...@kevinmehall.net Cc: Marek Czerski ma.czer...@gmail.com --- Notable changes: - Change flash0 to spansion,s25sl064p, due to kernel message m25p80 spi32766.0: found s25sl064p, expected m25p10 This is due to Altera changing the EPCS chip on newer revisions of that board, older versions are relabeled m25p10 and newer once s25sl064p. The change is fine though, you have to pick one. Stefan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
