Discussion:
[ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
Geert Uytterhoeven
2013-11-09 20:37:31 UTC
Permalink
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 at linux-m68k.org>
Cc: Kevin Mehall <contact at kevinmehall.net>
Cc: Marek Czerski <ma.czerski at 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 at 0 {
+ device_type = "memory";
+ reg = <0x00000000 0x02000000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 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 at 90000000 {
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+ reg = <0x90000000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <50000000>;
+ };
+
+ i2c0: ocores at 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 at 1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom at 50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0 at b0000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb0000000 0x5>;
+
+ flash0: mtd at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl064p";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ m25p,fast-read;
+
+ partition at 0 {
+ label = "FPGA image";
+ reg = <0x00000000 0x000b0000>;
+ read-only;
+ };
+ partition at b0000 {
+ label = "bootloader";
+ reg = <0x000b0000 0x00050000>;
+ read-only;
+ };
+ partition at 100000 {
+ label = "free space";
+ reg = <0x00100000 0x00700000>;
+ };
+ };
+ };
+
+ spi1: spi1 at b1000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
+ reg = <0xb1000000 0x5>;
+
+ adc at 0 {
+ compatible = "adcxx,adcxx8s";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ gpio0: gpio at 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
Stefan Kristiansson
2013-11-10 05:51:46 UTC
Permalink
Post by 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.
To give credit where credit is due, this was created by:
Gong Tao <gongtao0607 at gmail.com>
Post by Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Kevin Mehall <contact at kevinmehall.net>
Cc: Marek Czerski <ma.czerski at gmail.com>
---
- 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
Geert Uytterhoeven
2013-11-10 08:18:05 UTC
Permalink
On Sun, Nov 10, 2013 at 6:51 AM, Stefan Kristiansson
Post by Stefan Kristiansson
Post by 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.
Gong Tao <gongtao0607 at 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 at 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
Jonas Bonn
2013-11-15 09:52:25 UTC
Permalink
Post by Stefan Kristiansson
Post by Geert Uytterhoeven
- 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
Andrew Back
2013-11-15 10:04:04 UTC
Permalink
Post by Jonas Bonn
Post by Stefan Kristiansson
Post by Geert Uytterhoeven
- 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
Geert Uytterhoeven
2013-11-15 10:10:24 UTC
Permalink
Post by Andrew Back
P012060013
94V-0
HL9-VO
Same here.
Post by Andrew Back
1227 F
Mine says "1321 F"

Do you have the 8 MiB Spansion FL064PIF?
Post by Andrew Back
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 at 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
Andrew Back
2013-11-15 10:19:22 UTC
Permalink
Post by Geert Uytterhoeven
Post by Andrew Back
P012060013
94V-0
HL9-VO
Same here.
Post by Andrew Back
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
Jonas Bonn
2013-11-15 09:50:18 UTC
Permalink
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
Post by 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 at linux-m68k.org>
Cc: Kevin Mehall <contact at kevinmehall.net>
Cc: Marek Czerski <ma.czerski at gmail.com>
---
- 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?
Post by Geert Uytterhoeven
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&pic>;
+
+ chosen {
+ bootargs = "console=uart,mmio,0x90000000,115200";
+ };
+
+ memory at 0 {
+ device_type = "memory";
+ reg = <0x00000000 0x02000000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 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 at 90000000 {
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+ reg = <0x90000000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <50000000>;
+ };
+
+ i2c0: ocores at 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.
Post by Geert Uytterhoeven
+ reg = <0xa0000000 0x8>;
+ interrupts = <10>;
+ clock-frequency = <50000000>;
+
+ reg-shift = <0>; /* 8 bit registers */
+ reg-io-width = <1>; /* 8 bit read/write */
+
+ adxl34x at 1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom at 50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0 at b0000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "opencores,spi-simple";
Version number.
Post by Geert Uytterhoeven
+ reg = <0xb0000000 0x5>;
+
+ flash0: mtd at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl064p";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ m25p,fast-read;
+
+ partition at 0 {
+ label = "FPGA image";
+ reg = <0x00000000 0x000b0000>;
+ read-only;
+ };
+ partition at b0000 {
+ label = "bootloader";
+ reg = <0x000b0000 0x00050000>;
+ read-only;
+ };
+ partition at 100000 {
+ label = "free space";
+ reg = <0x00100000 0x00700000>;
+ };
+ };
+ };
+
+ spi1: spi1 at 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.
Post by Geert Uytterhoeven
+ reg = <0xb1000000 0x5>;
+
+ adc at 0 {
+ compatible = "adcxx,adcxx8s";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ gpio0: gpio at 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?
Post by Geert Uytterhoeven
+ 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
Geert Uytterhoeven
2013-11-15 10:22:22 UTC
Permalink
Hi Jonas,
Post by Geert Uytterhoeven
+++ 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.
Post by Geert Uytterhoeven
+ i2c0: ocores at 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.
Post by Geert Uytterhoeven
+ gpio0: gpio at 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?
Post by Geert Uytterhoeven
+ 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 at 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
Geert Uytterhoeven
2013-11-15 10:47:12 UTC
Permalink
On Fri, Nov 15, 2013 at 11:22 AM, Geert Uytterhoeven
Post by Geert Uytterhoeven
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 at 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
Jonas Bonn
2013-11-15 10:57:33 UTC
Permalink
Post by Geert Uytterhoeven
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...
Post by Geert Uytterhoeven
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?
Post by Geert Uytterhoeven
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
Olof Kindgren
2013-11-15 11:39:05 UTC
Permalink
2013/11/15 Jonas Bonn <jonas at southpole.se>
Post by Jonas Bonn
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
Post by Jonas Bonn
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

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


//Olof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20131115/69aec499/attachment.html>
Geert Uytterhoeven
2013-11-15 11:57:51 UTC
Permalink
Post by Olof Kindgren
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 at 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
Jonas Bonn
2013-11-15 12:12:49 UTC
Permalink
Post by Olof Kindgren
2013/11/15 Jonas Bonn <jonas at southpole.se>
Post by Jonas Bonn
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.
Post by Olof Kindgren
Post by Jonas Bonn
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.
Post by Olof Kindgren
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
Post by Olof Kindgren
//Olof
Stefan Kristiansson
2013-11-16 08:45:06 UTC
Permalink
Post by Jonas Bonn
Post by Geert Uytterhoeven
+
+ i2c0: ocores at 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
Olof Kindgren
2013-11-16 11:01:04 UTC
Permalink
2013/11/16 Stefan Kristiansson <stefan.kristiansson at saunalahti.fi>
Post by Stefan Kristiansson
Post by Jonas Bonn
+
+ i2c0: ocores at 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 at 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
Jonas Bonn
2013-11-17 08:44:40 UTC
Permalink
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.
Post by Olof Kindgren
2013/11/16 Stefan Kristiansson <stefan.kristiansson at saunalahti.fi>
Post by Stefan Kristiansson
Post by Jonas Bonn
+
+ i2c0: ocores at 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.
Post by Olof Kindgren
Post by Stefan Kristiansson
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.
Post by Olof Kindgren
Post by Stefan Kristiansson
Stefan
_______________________________________________
Linux mailing list
Linux at 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.
Post by Olof Kindgren
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
Stefan Kristiansson
2013-11-17 13:46:23 UTC
Permalink
Post by Olof Kindgren
2013/11/16 Stefan Kristiansson <stefan.kristiansson at saunalahti.fi>
Post by Jonas Bonn
Post by Jonas Bonn
+
+ i2c0: ocores at 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.
Actually, the i2c driver *is* upstream.
The remark was mostly meant as a reminder of that.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20131117/0644adb7/attachment.html>
Rob Herring
2013-11-20 20:45:28 UTC
Permalink
Post by 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 at linux-m68k.org>
Cc: Kevin Mehall <contact at kevinmehall.net>
Cc: Marek Czerski <ma.czerski at gmail.com>
---
- 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.
Post by Geert Uytterhoeven
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&pic>;
+
+ chosen {
+ bootargs = "console=uart,mmio,0x90000000,115200";
+ };
+
+ memory at 0 {
+ device_type = "memory";
+ reg = <0x00000000 0x02000000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 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 at 90000000 {
These memory mapped devices should be under a bus node of some sort.
Typically a "simple-bus" node.
Post by Geert Uytterhoeven
+ compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
This needs to be documented. Same comment applies to all compatible strings.
Post by Geert Uytterhoeven
+ reg = <0x90000000 0x100>;
+ interrupts = <2>;
+ clock-frequency = <50000000>;
+ };
+
+ i2c0: ocores at 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 at 1d {
+ compatible = "adxl34x";
+ reg = <0x1d>;
+ interrupts = <26>;
+ };
+ eeprom at 50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+ };
+
+ spi0: spi0 at 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

Loading...