[PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

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 <geert@linux-m68k.org>
Cc: Kevin Mehall <contact@kevinmehall.net>
Cc: Marek Czerski <ma.czerski@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 a0000000.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 000000000000..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,0x90000000,115200";
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x00000000 0x02000000>;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu@0 {
+			compatible = "opencores,or1200-rtlsvn481";
+			reg = <0>;
+			clock-frequency = <50000000>;
+		};
+	};
+
+	/*
+	 * 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@90000000 {
+		compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+		reg = <0x90000000 0x100>;
+		interrupts = <2>;
+		clock-frequency = <50000000>;
+	};
+
+	i2c0: ocores@a0000000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "opencores,i2c-ocores";
+		reg = <0xa0000000 0x8>;
+		interrupts = <10>;
+		clock-frequency = <50000000>;
+
+		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@b0000000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "opencores,spi-simple";
+		reg = <0xb0000000 0x5>;
+
+		flash0: mtd@0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "spansion,s25sl064p";
+			reg = <0>;
+			spi-max-frequency = <40000000>;
+			m25p,fast-read;
+
+			partition@0 {
+				label = "FPGA image";
+				reg = <0x00000000 0x000b0000>;
+				read-only;
+			};
+			partition@b0000 {
+				label = "bootloader";
+				reg = <0x000b0000 0x00050000>;
+				read-only;
+			};
+			partition@100000 {
+				label = "free space";
+				reg = <0x00100000 0x00700000>;
+			};
+		};
+	};
+
+	spi1: spi1@b1000000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "opencores,spi-simple";
+		reg = <0xb1000000 0x5>;
+
+		adc@0 {
+			compatible = "adcxx,adcxx8s";
+			reg = <0>;
+			spi-max-frequency = <1000000>;
+		};
+	};
+
+	gpio0: gpio@91000000 {
+		compatible = "opencores,jbtrivial";
+		reg = <0x91000000 0x2>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		xlnx,data-offset = <0>;
+		xlnx,tri-offset = <1>;
+		xlnx,gpio-width = <8>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		heartbeat {
+			label = "Heartbeat";
+			gpios = <&gpio0 0 0x0>;
+			linux,default-trigger = "heartbeat";
+		};
+		led1 {
+			label = "led1";
+			gpios = <&gpio0 1 0>;
+		};
+		led2 {
+			label = "led2";
+			gpios = <&gpio0 2 0>;
+		};
+		led3 {
+			label = "led3";
+			gpios = <&gpio0 3 0>;
+		};
+		led4 {
+			label = "led4";
+			gpios = <&gpio0 4 0>;
+		};
+		led5 {
+			label = "led5";
+			gpios = <&gpio0 5 0>;
+		};
+		led6 {
+			label = "led6";
+			gpios = <&gpio0 6 0>;
+		};
+		led7 {
+			label = "led7";
+			gpios = <&gpio0 7 0>;
+		};
+	};
+};
diff --git a/arch/openrisc/configs/de0_nano_defconfig b/arch/openrisc/configs/de0_nano_defconfig
new file mode 100644
index 000000000000..bce8f4862e5e
--- /dev/null
+++ b/arch/openrisc/configs/de0_nano_defconfig
@@ -0,0 +1,86 @@
+CONFIG_CROSS_COMPILE="or32-linux-"
+CONFIG_NO_HZ=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="arch/openrisc/support/initramfs arch/openrisc/support/initramfs.devnodes"
+# CONFIG_RD_GZIP is not set
+CONFIG_EXPERT=y
+# CONFIG_KALLSYMS is not set
+# CONFIG_EPOLL is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLOB=y
+CONFIG_MODULES=y
+# CONFIG_BLOCK is not set
+CONFIG_OPENRISC_BUILTIN_DTB="de0_nano"
+CONFIG_HZ_100=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_CUBIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_M25P80=y
+# CONFIG_M25PXX_USE_FAST_READ is not set
+CONFIG_PROC_DEVICETREE=y
+CONFIG_EEPROM_AT24=y
+CONFIG_NETDEVICES=y
+# CONFIG_ETHERNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_ADXL34X=y
+# CONFIG_INPUT_ADXL34X_SPI is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_OCORES=y
+CONFIG_SPI=y
+CONFIG_SPI_OCSIMPLE=y
+CONFIG_GPIO_JBTRIVIAL=y
+CONFIG_SENSORS_ADCXX=y
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+# CONFIG_DNOTIFY is not set
+CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
-- 
1.7.9.5

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Stefan Kristiansson]

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 <gongtao0607@gmail.com>

> 
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Kevin Mehall <contact@kevinmehall.net>
> Cc: Marek Czerski <ma.czerski@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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

On Sun, Nov 10, 2013 at 6:51 AM, Stefan Kristiansson
<stefan.kristiansson@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 <gongtao0607@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 -- geert@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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Jonas Bonn]

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 <geert@linux-m68k.org>
> Cc: Kevin Mehall <contact@kevinmehall.net>
> Cc: Marek Czerski <ma.czerski@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 a0000000.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 000000000000..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,0x90000000,115200";
> +	};
> +
> +	memory@0 {
> +		device_type = "memory";
> +		reg = <0x00000000 0x02000000>;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cpu@0 {
> +			compatible = "opencores,or1200-rtlsvn481";
> +			reg = <0>;
> +			clock-frequency = <50000000>;
> +		};
> +	};
> +
> +	/*
> +	 * 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@90000000 {
> +		compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
> +		reg = <0x90000000 0x100>;
> +		interrupts = <2>;
> +		clock-frequency = <50000000>;
> +	};
> +
> +	i2c0: ocores@a0000000 {
> +		#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 = <0xa0000000 0x8>;
> +		interrupts = <10>;
> +		clock-frequency = <50000000>;
> +
> +		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@b0000000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "opencores,spi-simple";

Version number.

> +		reg = <0xb0000000 0x5>;
> +
> +		flash0: mtd@0 {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "spansion,s25sl064p";
> +			reg = <0>;
> +			spi-max-frequency = <40000000>;
> +			m25p,fast-read;
> +
> +			partition@0 {
> +				label = "FPGA image";
> +				reg = <0x00000000 0x000b0000>;
> +				read-only;
> +			};
> +			partition@b0000 {
> +				label = "bootloader";
> +				reg = <0x000b0000 0x00050000>;
> +				read-only;
> +			};
> +			partition@100000 {
> +				label = "free space";
> +				reg = <0x00100000 0x00700000>;
> +			};
> +		};
> +	};
> +
> +	spi1: spi1@b1000000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "opencores,spi-simple";

Version number needed.  OpenCores wanted "projectname-rtlsvn###" where 
### is the SVN commit number of the RTL directory in the project's 
source repository.

> +		reg = <0xb1000000 0x5>;
> +
> +		adc@0 {
> +			compatible = "adcxx,adcxx8s";
> +			reg = <0>;
> +			spi-max-frequency = <1000000>;
> +		};
> +	};
> +
> +	gpio0: gpio@91000000 {
> +		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 = <0x91000000 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.

/Jonas

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Jonas Bonn]

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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Andrew Back]

On 15 November 2013 09:52, Jonas Bonn <jonas@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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back <andrew@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 -- geert@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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Andrew Back]

On 15 November 2013 10:10, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Nov 15, 2013 at 11:04 AM, Andrew Back <andrew@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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

Hi Jonas,

On Fri, Nov 15, 2013 at 10:50 AM, Jonas Bonn <jonas@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@a0000000 {
>> +               #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@91000000 {
>> +               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 = <0x91000000 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 -- geert@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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

On Fri, Nov 15, 2013 at 11:22 AM, Geert Uytterhoeven
<geert@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 -- geert@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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[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...

>>
>> 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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Geert Uytterhoeven]

On Fri, Nov 15, 2013 at 12:39 PM, Olof Kindgren <olof.kindgren@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 -- geert@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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Jonas Bonn]

On 11/15/2013 12:39 PM, Olof Kindgren wrote:
> 2013/11/15 Jonas Bonn <jonas@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
>

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Mark Rutland]

On Fri, Nov 15, 2013 at 09:50:18AM +0000, Jonas Bonn wrote:
[...]

> > +	gpio0: gpio@91000000 {
> > +		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.

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Mark Rutland]

[...]

> >>>> 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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Stefan Kristiansson]

On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> >+
> >+	i2c0: ocores@a0000000 {
> >+		#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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Olof Kindgren]

2013/11/16 Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
>
> On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> > >+
> > >+    i2c0: ocores@a0000000 {
> > >+            #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
> Linux@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

Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Jonas Bonn]

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.kristiansson@saunalahti.fi>
>> On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
>>>> +
>>>> +    i2c0: ocores@a0000000 {
>>>> +            #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
>> Linux@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

Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano

[Rob Herring]

On Sat, Nov 9, 2013 at 2:37 PM, Geert Uytterhoeven <geert@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 <geert@linux-m68k.org>
> Cc: Kevin Mehall <contact@kevinmehall.net>
> Cc: Marek Czerski <ma.czerski@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 a0000000.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 000000000000..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,0x90000000,115200";
> +       };
> +
> +       memory@0 {
> +               device_type = "memory";
> +               reg = <0x00000000 0x02000000>;
> +       };
> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               cpu@0 {
> +                       compatible = "opencores,or1200-rtlsvn481";
> +                       reg = <0>;
> +                       clock-frequency = <50000000>;
> +               };
> +       };
> +
> +       /*
> +        * 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@90000000 {

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 = <0x90000000 0x100>;
> +               interrupts = <2>;
> +               clock-frequency = <50000000>;
> +       };
> +
> +       i2c0: ocores@a0000000 {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               compatible = "opencores,i2c-ocores";
> +               reg = <0xa0000000 0x8>;
> +               interrupts = <10>;
> +               clock-frequency = <50000000>;
> +
> +               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@b0000000 {
> +               #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