Add MPC5200B base board mvBC-P

PATCH Superseded Andre Schwarz 4 participants 10 messages Jul 4, 2008 – Jul 8, 2008

Subsystems (3)

Device tree bindings PowerPC Linux for PowerPC embedded MPC5XXX

lore

Share & tools

lore

Andre Schwarz

author

2008-07-04 16:35 UTC #0 lore raw

PATCH 1/1 Add MPC5200B base board mvBC-P

The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet controller (using e1000). It's just another MPC5200_simple board.

Signed-off-by Andre Schwarz <[email protected]>

---

Grant,

I don't know if there are any merge windows ...
If the patch should be modified or re-submitted on a later time please let me know.

thanks,
Andre

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

 arch/powerpc/boot/dts/mvbc-p.dts             |  206 +++++
 arch/powerpc/configs/mvbc-p_defconfig        | 1158 ++++++++++++++++++++++++++
 arch/powerpc/platforms/52xx/Kconfig          |    3 +-
 arch/powerpc/platforms/52xx/mpc5200_simple.c |    1 +
 4 files changed, 1367 insertions(+), 1 deletions(-)

arch/powerpc/boot/dts/mvbc-p.dts new file +206 -0

new file mode 100644
index 0000000..90a2808
@@ -0,0 +1,206 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+	model = "matrix-vision,mvbc-p";
+	compatible = "matrix-vision,mvbc-p";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,5200@0 {
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-line-size = <32>;
+			i-cache-line-size = <32>;
+			d-cache-size = <0x4000>;
+			i-cache-size = <0x4000>;
+			timebase-frequency = <0>;
+			bus-frequency = <0>;
+			clock-frequency = <0>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000>;
+	};
+
+	soc5200@f0000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc5200-immr";
+		ranges = <0 0xf0000000 0x0000c000>;
+		reg = <0xf0000000 0x00000100>;
+		bus-frequency = <0>;
+		system-frequency = <0>;
+
+		cdm@200 {
+			compatible = "fsl,mpc5200-cdm";
+			reg = <0x200 0x38>;
+		};
+
+		mpc5200_pic: interrupt-controller@500 {
+			// 5200 interrupts are encoded into two levels;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			compatible = "fsl,mpc5200-pic";
+			reg = <0x500 0x80>;
+		};
+
+		timer@600 {	// General Purpose Timer
+			compatible = "fsl,mpc5200-gpt";
+			reg = <0x600 0x10>;
+			interrupts = <1 9 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl,has-wdt;
+		};
+
+		gpio@b00 {
+			compatible = "fsl,mpc5200-gpio";
+			reg = <0xb00 0x40>;
+			interrupts = <1 7 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		gpio@c00 {
+			compatible = "fsl,mpc5200-gpio-wkup";
+			reg = <0xc00 0x40>;
+			interrupts = <1 8 0 0 3 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		dma-controller@1200 {
+			device_type = "dma-controller";
+			compatible = "fsl,mpc5200-bestcomm";
+			reg = <0x1200 0x80>;
+			interrupts = <3 0 0  3 1 0  3 2 0  3 3 0
+				3 4 0  3 5 0  3 6 0  3 7 0
+				3 8 0  3 9 0  3 10 0  3 11 0
+				3 12 0  3 13 0  3 14 0  3 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		xlb@1f00 {
+			compatible = "fsl,mpc5200-xlb";
+			reg = <0x1f00 0x100>;
+		};
+
+		serial0: serial@2000 {		// PSC1
+			device_type = "serial";
+			compatible = "fsl,mpc5200-psc-uart";
+			port-number = <0>;
+			reg = <0x2000 0x100>;
+			interrupts = <2 1 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		i2c@3d00 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d00 0x40>;
+			interrupts = <2 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+
+		i2c@3d40 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d40 0x40>;
+			interrupts = <2 16 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+		sram@8000 {
+			compatible = "fsl,mpc5200-sram","sram";
+			reg = <0x8000 0x4000>;
+		};
+	};
+
+	lpb {
+		compatible = "fsl,lpb";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0xff800000 0x00800000>;
+		flash@0,0 {
+			compatible = "cfi-flash";
+			reg = <0 0 0x800000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			bank-width = <1>;
+			device-width = <1>;
+			nor_total@0x0 {
+				reg = <0x0 0x800000>;
+			};
+			u-boot@0x0 {
+				reg = <0x0 0x40000>;
+			};
+			u-boot_autoscript@0x40000 {
+				reg = <0x40000 0x10000>;
+			};
+			u-boot_autoscript_red@0x50000 {
+				reg = <0x50000 0x10000>;
+			};
+			fpga@0x60000 {
+				reg = <0x60000 0x40000>;
+			};
+			user@0xa0000 {
+				reg = <0xa00000 0x60000>;
+			};
+			rfs@0x100000 {
+				reg = <0x100000 0x300000>;
+			};
+			kernel@0x400000 {
+				reg = <0x400000 0x3c0000>;
+			};
+			dtb@0x7c0000 {
+				reg = <0x7c0000 0x10000>;
+			};
+			dtb@0x7d0000 {
+				reg = <0x7d0000 0x10000>;
+			};
+			ppcboot_env@0x7e0000 {
+				reg = <0x7e0000 0x10000>;
+			};
+			ppcboot_env@0x7f0000 {
+				reg = <0x7f0000 0x10000>;
+			};
+		};
+	};
+
+	pci: pci@0xf0000d00 {
+		#interrupt-cells = <1>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		device_type = "pci";
+		compatible = "fsl,mpc5200-pci";
+		reg = <0xf0000d00 0x100>;
+		interrupt-map-mask = <0xf800 0 0 7>;
+		interrupt-map = <0x5800 0 0 1 &mpc5200_pic 1 2 3
+			0x5000 0 0 1 &mpc5200_pic 1 3 3>;
+		clock-frequency = <0>;
+		interrupts = <2 8 0 2 9 0 2 10 0>;
+		interrupt-parent = <&mpc5200_pic>;
+		bus-range = <0 0>;
+		ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
+			0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+			0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
+	};
+};

arch/powerpc/configs/mvbc-p_defconfig new file +1158 -0

1,158 lines not on this page · raw message

arch/powerpc/platforms/52xx/Kconfig +2 -1

index acd2fc8..d2960a9 100644
@@ -21,7 +21,8 @@ config PPC_MPC5200_SIMPLE
 	    and if there is a PCI bus node defined in the device tree.
 
 	  Boards that are compatible with this generic platform support
-	  are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+	  are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200' and
+	       'matrix-vision,mvbc-p'.
 
 config PPC_EFIKA
 	bool "bPlan Efika 5k2. MPC5200B based computer"

arch/powerpc/platforms/52xx/mpc5200_simple.c +1 -0

index a3bda0b..6423675 100644
@@ -54,6 +54,7 @@ static char *board[] __initdata = {
 	"phytec,pcm030",
 	"schindler,cm5200",
 	"tqc,tqm5200",
+	"matrix-vision,mvbc-p",
 	NULL
 };

Grant Likely

2008-07-04 17:00 UTC #1 lore raw

Quoted 11 lines · Andre Schwarz

The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by Andre Schwarz <[email protected]>
---
Grant,
I don't know if there are any merge windows ...
If the patch should be modified or re-submitted on a later time please let me know.

The merge window will be opening any day now. If you address comments quickly then I should be able to merge it into 2.6.27

Quoted 2 lines

 arch/powerpc/boot/dts/mvbc-p.dts             |  206 +++++
 arch/powerpc/configs/mvbc-p_defconfig        | 1158 ++++++++++++++++++++++++++

Rename this to arch/powerpc/config/52xx/mvbc_p_defconfig (use platform specific defconfig dir and don't mix '-' and '_' in filenames).

Quoted 42 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +36 -0

new file mode 100644
index 0000000..90a2808
@@ -0,0 +1,206 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+	model = "matrix-vision,mvbc-p";
+	compatible = "matrix-vision,mvbc-p";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,5200@0 {
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-line-size = <32>;
+			i-cache-line-size = <32>;
+			d-cache-size = <0x4000>;
+			i-cache-size = <0x4000>;
+			timebase-frequency = <0>;
+			bus-frequency = <0>;
+			clock-frequency = <0>;
+		};
+	};

arch/powerpc/boot/dts/mvbc-p.dts line 46

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +10 -0

+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000>;
+	};
+
+	soc5200@f0000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc5200-immr";

Does this board use the original 5200, or the 5200B? If it uses the 5200B, then you should specify both fsl,mpc5200b-immr and fsl,mpc5200-immr. Same goes for all other compatible properties in the tree; see lite5200b.dts for an example.

I am toying with the option of eliminating the need for fsl,mpc5200b-*, but until then the conservative and safest thing to do is to claim compatibility with both.

arch/powerpc/boot/dts/mvbc-p.dts line 138

Quoted 2 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +2 -0
+	lpb {
+		compatible = "fsl,lpb";

You should also claim compatibility with "simple-bus" here.

ie: compatible = "fsl,lpb", "simple-bus";

arch/powerpc/boot/dts/mvbc-p.dts line 143

Quoted 5 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +5 -0

+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0xff800000 0x00800000>;
+		flash@0,0 {
+			compatible = "cfi-flash";

For completeness, it is good practice for the first entry in the compatible list to be the actual flash chip, followed by "cfi-flash"

arch/powerpc/boot/dts/mvbc-p.dts line 151

Quoted 8 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +8 -0

+			reg = <0 0 0x800000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			bank-width = <1>;
+			device-width = <1>;
+			nor_total@0x0 {
+				reg = <0x0 0x800000>;
+			};

I don't know if this is legal; to have overlapping flash sections (but I'm not a cfi-flash binding expert).

Quoted 23 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +23 -0

+			u-boot@0x0 {
+				reg = <0x0 0x40000>;
+			};
+			u-boot_autoscript@0x40000 {
+				reg = <0x40000 0x10000>;
+			};
+			u-boot_autoscript_red@0x50000 {
+				reg = <0x50000 0x10000>;
+			};
+			fpga@0x60000 {
+				reg = <0x60000 0x40000>;
+			};
+			user@0xa0000 {
+				reg = <0xa00000 0x60000>;
+			};
+			rfs@0x100000 {
+				reg = <0x100000 0x300000>;
+			};
+			kernel@0x400000 {
+				reg = <0x400000 0x3c0000>;
+			};
+			dtb@0x7c0000 {
+				reg = <0x7c0000 0x10000>;

arch/powerpc/boot/dts/mvbc-p.dts line 184

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +10 -0

+			};
+			dtb@0x7d0000 {
+				reg = <0x7d0000 0x10000>;
+			};
+			ppcboot_env@0x7e0000 {
+				reg = <0x7e0000 0x10000>;
+			};
+			ppcboot_env@0x7f0000 {
+				reg = <0x7f0000 0x10000>;
+			};

I think it would be better to just leave out the partition information and modify U-Boot to fill them in (just like memory and clock speed are left out). Things like flash partitions are less like hardware description and more like configuration data.

Quoted 22 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +22 -0

+		};
+	};
+
+	pci: pci@0xf0000d00 {
+		#interrupt-cells = <1>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		device_type = "pci";
+		compatible = "fsl,mpc5200-pci";
+		reg = <0xf0000d00 0x100>;
+		interrupt-map-mask = <0xf800 0 0 7>;
+		interrupt-map = <0x5800 0 0 1 &mpc5200_pic 1 2 3
+			0x5000 0 0 1 &mpc5200_pic 1 3 3>;
+		clock-frequency = <0>;
+		interrupts = <2 8 0 2 9 0 2 10 0>;
+		interrupt-parent = <&mpc5200_pic>;
+		bus-range = <0 0>;
+		ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
+			0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+			0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
+	};
+};

Jon Smirl

2008-07-04 17:27 UTC #2 lore raw

Quoted 56 lines · Grant Likely

arch/powerpc/boot/dts/mvbc-p.dts line 143

Quoted 5 lines · Andre Schwarz

arch/powerpc/boot/dts/mvbc-p.dts new file +5 -0

+             #address-cells = <2>;
+             #size-cells = <1>;
+             ranges = <0x0 0x0 0xff800000 0x00800000>;
+             flash@0,0 {
+                     compatible = "cfi-flash";

For completeness, it is good practice for the first entry in the compatible list to be the actual flash chip, followed by "cfi-flash"

arch/powerpc/boot/dts/mvbc-p.dts line 151

Quoted 8 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +8 -0

+                     reg = <0 0 0x800000>;
+                     #address-cells = <1>;
+                     #size-cells = <1>;
+                     bank-width = <1>;
+                     device-width = <1>;
+                     nor_total@0x0 {
+                             reg = <0x0 0x800000>;
+                     };

I don't know if this is legal; to have overlapping flash sections (but I'm not a cfi-flash binding expert).

Quoted 23 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +23 -0

+                     u-boot@0x0 {
+                             reg = <0x0 0x40000>;
+                     };
+                     u-boot_autoscript@0x40000 {
+                             reg = <0x40000 0x10000>;
+                     };
+                     u-boot_autoscript_red@0x50000 {
+                             reg = <0x50000 0x10000>;
+                     };
+                     fpga@0x60000 {
+                             reg = <0x60000 0x40000>;
+                     };
+                     user@0xa0000 {
+                             reg = <0xa00000 0x60000>;
+                     };
+                     rfs@0x100000 {
+                             reg = <0x100000 0x300000>;
+                     };
+                     kernel@0x400000 {
+                             reg = <0x400000 0x3c0000>;
+                     };
+                     dtb@0x7c0000 {
+                             reg = <0x7c0000 0x10000>;

arch/powerpc/boot/dts/mvbc-p.dts line 184

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +10 -0

+                     };
+                     dtb@0x7d0000 {
+                             reg = <0x7d0000 0x10000>;
+                     };
+                     ppcboot_env@0x7e0000 {
+                             reg = <0x7e0000 0x10000>;
+                     };
+                     ppcboot_env@0x7f0000 {
+                             reg = <0x7f0000 0x10000>;
+                     };

Quoted 4 lines

I think it would be better to just leave out the partition information and modify U-Boot to fill them in (just like memory and clock speed are left out). Things like flash partitions are less like hardware description and more like configuration data.

Has anyone tried writing a RedBoot type partition table onto their flash device? If it is there the kernel will read the partition info from it. It's a config option in the kernel flash support section. Is there a utility for creating these tables?

Signature · 2 lines

Jon Smirl
[email protected]

André Schwarz

author

2008-07-05 09:32 UTC #3 lore raw

In reply to Grant Likely

Grant,

thanks for the quick feedback - I'll try to improve. Hopefully monday morning will be on time ....

Comments inline.

regards,
André

Quoted 9 lines · Grant Likely

Quoted 7 lines · Andre Schwarz
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by Andre Schwarz <[email protected]>
---

Quoted 10 lines

Quoted 5 lines
Grant,
I don't know if there are any merge windows ...
If the patch should be modified or re-submitted on a later time please let me know.
The merge window will be opening any day now. If you address comments quickly then I should be able to merge it into 2.6.27

great.

Quoted 7 lines

Quoted 3 lines
 arch/powerpc/boot/dts/mvbc-p.dts             |  206 +++++
 arch/powerpc/configs/mvbc-p_defconfig        | 1158 ++++++++++++++++++++++++++
Rename this to arch/powerpc/config/52xx/mvbc_p_defconfig (use platform specific defconfig dir and don't mix '-' and '_' in filenames).

ok - no problem.

Quoted 59 lines

Quoted 43 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +36 -0

new file mode 100644
index 0000000..90a2808
@@ -0,0 +1,206 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+	model = "matrix-vision,mvbc-p";
+	compatible = "matrix-vision,mvbc-p";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,5200@0 {
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-line-size = <32>;
+			i-cache-line-size = <32>;
+			d-cache-size = <0x4000>;
+			i-cache-size = <0x4000>;
+			timebase-frequency = <0>;
+			bus-frequency = <0>;
+			clock-frequency = <0>;
+		};
+	};

arch/powerpc/boot/dts/mvbc-p.dts line 46

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +10 -0

+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000>;
+	};
+
+	soc5200@f0000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc5200-immr";

Quoted 5 lines

I am toying with the option of eliminating the need for fsl,mpc5200b-*, but until then the conservative and safest thing to do is to claim compatibility with both.

It's a MPC5200B. I thought that the "b"-Option has already out of use after reading about this a few weeks ago ... maybe I misinterpreted. I'll fix this.

Quoted 9 lines

arch/powerpc/boot/dts/mvbc-p.dts line 138
Quoted 3 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +2 -0
+	lpb {
+		compatible = "fsl,lpb";
You should also claim compatibility with "simple-bus" here.
ie: compatible = "fsl,lpb", "simple-bus";

ok.

Quoted 11 lines

arch/powerpc/boot/dts/mvbc-p.dts line 143
Quoted 6 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +5 -0
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0x0 0x0 0xff800000 0x00800000>;
+		flash@0,0 {
+			compatible = "cfi-flash";
For completeness, it is good practice for the first entry in the compatible list to be the actual flash chip, followed by "cfi-flash"

ok.

Quoted 4 lines

Quoted 4 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +4 -0
+			reg = <0 0 0x800000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			bank-width = <1>;

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts line 151
Quoted 5 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +4 -0
+			device-width = <1>;
+			nor_total@0x0 {
+				reg = <0x0 0x800000>;
+			};
I don't know if this is legal; to have overlapping flash sections (but I'm not a cfi-flash binding expert).

Hopefully this is still possible. Nested mtd partitions have always been possible, e.g. embedded environment inside u-boot partition. It's proven very useful to have access to the whole chip - so it's possible to make binary updates even with the partition layout changing .... I'd really like to stick to it if you don't mind.

Quoted 31 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +31 -0

+			u-boot@0x0 {
+				reg = <0x0 0x40000>;
+			};
+			u-boot_autoscript@0x40000 {
+				reg = <0x40000 0x10000>;
+			};
+			u-boot_autoscript_red@0x50000 {
+				reg = <0x50000 0x10000>;
+			};
+			fpga@0x60000 {
+				reg = <0x60000 0x40000>;
+			};
+			user@0xa0000 {
+				reg = <0xa00000 0x60000>;
+			};
+			rfs@0x100000 {
+				reg = <0x100000 0x300000>;
+			};
+			kernel@0x400000 {
+				reg = <0x400000 0x3c0000>;
+			};
+			dtb@0x7c0000 {
+				reg = <0x7c0000 0x10000>;
+			};
+			dtb@0x7d0000 {
+				reg = <0x7d0000 0x10000>;
+			};
+			ppcboot_env@0x7e0000 {
+				reg = <0x7e0000 0x10000>;
+			};
+			ppcboot_env@0x7f0000 {

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts line 94
Quoted 3 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +2 -0
+				reg = <0x7f0000 0x10000>;
+			};
I think it would be better to just leave out the partition information and modify U-Boot to fill them in (just like memory and clock speed are left out). Things like flash partitions are less like hardware description and more like configuration data.

never did this. Is it quick'n'easy ?
Honestly I don't like the bootloader to set up everything.
If you need any change it will require a bootloader update which is a very fragile operation out in the field.
There will always be bricked systems afterwards ....
Failure in updating the (redundant) dtb blob or kernel will do almost always no harm since the system is still accessible and flashable using ethernet or serial.

If it's not against all rule (which I don't think) I'd really like to stick to it, too. Is this ok ?

Quoted 15 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +15 -0

+		};
+	};
+
+	pci: pci@0xf0000d00 {
+		#interrupt-cells = <1>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		device_type = "pci";
+		compatible = "fsl,mpc5200-pci";
+		reg = <0xf0000d00 0x100>;
+		interrupt-map-mask = <0xf800 0 0 7>;
+		interrupt-map = <0x5800 0 0 1 &mpc5200_pic 1 2 3
+			0x5000 0 0 1 &mpc5200_pic 1 3 3>;
+		clock-frequency = <0>;
+		interrupts = <2 8 0 2 9 0 2 10 0>;

Quoted 8 lines

arch/powerpc/boot/dts/mvbc-p.dts line 206

Quoted 8 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +7 -0

+		interrupt-parent = <&mpc5200_pic>;
+		bus-range = <0 0>;
+		ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
+			0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+			0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
+	};
+};

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Grant Likely

2008-07-05 16:13 UTC #4 lore raw

Quoted 1 line · On Sat, Jul 5, 2008 at 3:32 AM, Andr=E9 Schwarz…

It's a MPC5200B. I thought that the "b"-Option has already out of use aft=

Quoted 1 line

reading about this a few weeks ago ... maybe I misinterpreted.

No, I'm *toying* with the idea, but I haven't decided yet.

Quoted 8 lines

Quoted 4 lines
I think it would be better to just leave out the partition information and modify U-Boot to fill them in (just like memory and clock speed are left out). Things like flash partitions are less like hardware description and more like configuration data.
never did this. Is it quick'n'easy ?
Honestly I don't like the bootloader to set up everything.
If you need any change it will require a bootloader update which is a ver=

Quoted 3 lines

fragile operation out in the field.
There will always be bricked systems afterwards ....
Failure in updating the (redundant) dtb blob or kernel will do almost alw=

ays

Quoted 1 line

no harm since the system is still accessible and flashable using ethernet=

Quoted 3 lines

serial.
If it's not against all rule (which I don't think) I'd really like to sti=

Quoted 2 lines

to it, too.
Is this ok ?

hurumm... okay, leave it in. I suppose it isn't a risky thing to do.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

David Gibson

2008-07-06 23:50 UTC #5 lore raw

In reply to Andre Schwarz

Quoted 4 lines · Andre Schwarz

The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by Andre Schwarz <[email protected]>

[snip]

Quoted 3 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +0 -0
@@ -0,0 +1,206 @@

[snip]

arch/powerpc/boot/dts/mvbc-p.dts line 88

Quoted 2 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +2 -0
+		dma-controller@1200 {
+			device_type = "dma-controller";

No device_type here.

Quoted 47 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +47 -0

+			compatible = "fsl,mpc5200-bestcomm";
+			reg = <0x1200 0x80>;
+			interrupts = <3 0 0  3 1 0  3 2 0  3 3 0
+				3 4 0  3 5 0  3 6 0  3 7 0
+				3 8 0  3 9 0  3 10 0  3 11 0
+				3 12 0  3 13 0  3 14 0  3 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		xlb@1f00 {
+			compatible = "fsl,mpc5200-xlb";
+			reg = <0x1f00 0x100>;
+		};
+
+		serial0: serial@2000 {		// PSC1
+			device_type = "serial";
+			compatible = "fsl,mpc5200-psc-uart";
+			port-number = <0>;
+			reg = <0x2000 0x100>;
+			interrupts = <2 1 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		i2c@3d00 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d00 0x40>;
+			interrupts = <2 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+
+		i2c@3d40 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d40 0x40>;
+			interrupts = <2 16 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+		sram@8000 {
+			compatible = "fsl,mpc5200-sram","sram";
+			reg = <0x8000 0x4000>;
+		};
+	};

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Andre Schwarz

author

2008-07-07 07:49 UTC #6 lore raw

David,

thanks - removed "device_type" from the DMA controller.

Which nodes actually require "device_type" and which don't ?

Is there some general rule ?

regards,
Andre

Quoted 63 lines · David Gibson

Quoted 5 lines · Andre Schwarz

The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by Andre Schwarz <[email protected]>

[snip]

Quoted 4 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +0 -0
@@ -0,0 +1,206 @@

[snip]

arch/powerpc/boot/dts/mvbc-p.dts line 88

Quoted 3 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +2 -0
+		dma-controller@1200 {
+			device_type = "dma-controller";

No device_type here.

Quoted 40 lines

arch/powerpc/boot/dts/mvbc-p.dts new file +40 -0

+			compatible = "fsl,mpc5200-bestcomm";
+			reg = <0x1200 0x80>;
+			interrupts = <3 0 0  3 1 0  3 2 0  3 3 0
+				3 4 0  3 5 0  3 6 0  3 7 0
+				3 8 0  3 9 0  3 10 0  3 11 0
+				3 12 0  3 13 0  3 14 0  3 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		xlb@1f00 {
+			compatible = "fsl,mpc5200-xlb";
+			reg = <0x1f00 0x100>;
+		};
+
+		serial0: serial@2000 {		// PSC1
+			device_type = "serial";
+			compatible = "fsl,mpc5200-psc-uart";
+			port-number = <0>;
+			reg = <0x2000 0x100>;
+			interrupts = <2 1 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		i2c@3d00 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d00 0x40>;
+			interrupts = <2 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+
+		i2c@3d40 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200-i2c","fsl-i2c";
+			reg = <0x3d40 0x40>;
+			interrupts = <2 16 0>;
+			interrupt-parent = <&mpc5200_pic>;

Quoted 10 lines

arch/powerpc/boot/dts/mvbc-p.dts line 135
Quoted 8 lines
arch/powerpc/boot/dts/mvbc-p.dts new file +7 -0
+			fsl5200-clocking;
+		};
+		sram@8000 {
+			compatible = "fsl,mpc5200-sram","sram";
+			reg = <0x8000 0x4000>;
+		};
+	};

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Grant Likely

2008-07-07 14:12 UTC #7 lore raw

Quoted 7 lines · Andre Schwarz

David,
thanks - removed "device_type" from the DMA controller.
Which nodes actually require "device_type" and which don't ?
Is there some general rule ?

Segher, David;

In OF, what is the purpose of device_type? From what I understand right now, each value of device_type claims a software interface that the device supports. So for example, device_type = "serial" means that firmware supports using the device as a serial port, correct? So, similarly, if OF did not have a driver for the device, then the presence a device_type property would be a bug, right?

Does device_type indicated any other information other than firmware driver interface?

I had an epiphany about device_type this weekend (and by epiphany, I mean realizing my own stupidity). If I'm correct about the above questions, then that would mean it is *always* a bug to have a device_type property in .dts file because there is no firmware interface. So, it seems to me that we shouldn't just be eliminating undefined device_type values, but also eliminate the ones that are defined in OF because .dts users do not support the firmware driver interface.

Am I correct?

The only situation where I can see it being appropriate to specify device_type is to work around older bindings that are ambiguous with their other properties.

Signature · 2 lines

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Jon Smirl

2008-07-07 18:51 UTC #8 lore raw

Quoted 32 lines · Grant Likely

Quoted 7 lines · Andre Schwarz
David,
thanks - removed "device_type" from the DMA controller.
Which nodes actually require "device_type" and which don't ?
Is there some general rule ?
Segher, David;
In OF, what is the purpose of device_type? From what I understand right now, each value of device_type claims a software interface that the device supports. So for example, device_type = "serial" means that firmware supports using the device as a serial port, correct? So, similarly, if OF did not have a driver for the device, then the presence a device_type property would be a bug, right?
Does device_type indicated any other information other than firmware driver interface?
I had an epiphany about device_type this weekend (and by epiphany, I mean realizing my own stupidity). If I'm correct about the above questions, then that would mean it is *always* a bug to have a device_type property in .dts file because there is no firmware interface. So, it seems to me that we shouldn't just be eliminating undefined device_type values, but also eliminate the ones that are defined in OF because .dts users do not support the firmware driver interface.

Quoted 5 lines

Am I correct?
The only situation where I can see it being appropriate to specify device_type is to work around older bindings that are ambiguous with their other properties.

I experimented with this on my own trees.

			device_type = "serial";

Is current required on the boot console or it will disappear.

Signature · 2 lines

Jon Smirl
[email protected]

David Gibson

2008-07-08 03:41 UTC #9 lore raw

In reply to Grant Likely

Quoted 8 lines · Grant Likely

Quoted 6 lines · Andre Schwarz
David,
thanks - removed "device_type" from the DMA controller.
Which nodes actually require "device_type" and which don't ?

Quoted 8 lines

Quoted 1 line
Is there some general rule ?
Segher, David;
In OF, what is the purpose of device_type? From what I understand right now, each value of device_type claims a software interface that the device supports. So for example, device_type = "serial" means that firmware supports using the device as a serial port, correct?

That's correct. And more specially allows using it as a serial port using the OF defined method interface.

Quoted 2 lines

So, similarly, if OF did not have a driver for the device, then the presence a device_type property would be a bug, right?

Um.. not precisely sure about this case, don't know if 1275 allows device nodes with no OF driver / method interface.

Quoted 2 lines

Does device_type indicated any other information other than firmware driver interface?

In theory, no. In practice... sort of, sometimes, maybe.

Quoted 10 lines

I had an epiphany about device_type this weekend (and by epiphany, I mean realizing my own stupidity). If I'm correct about the above questions, then that would mean it is *always* a bug to have a device_type property in .dts file because there is no firmware interface. So, it seems to me that we shouldn't just be eliminating undefined device_type values, but also eliminate the ones that are defined in OF because .dts users do not support the firmware driver interface.
Am I correct?

Again, in theory, yes. In practice.. maybe.

As you say, device_type is only supposed to describe the firmware provided software-interface and should not be used for other device identification purposes. However, because device_type used to be present on basically everything, it sometimes is, by Linux and presumably also by other OSes.

We certainly don't want to encourage or perpetuate that incorrect use, which is why we're so insistent that people don't invent new device_type values or use ones that aren't described in the existing 1275 bindings.

There are the few "special" devices that don't typically have 'compatible' values, so there isn't really any way to identify them other than 'device_type' and name. That's the memory and cpu nodes typically, and sometimes pci IIRC (PCI bridges really should have a compatible value to describe their register interface, but I have a feeling they fairly often don't). ISA nodes may fall in this category too, I forget. I am strongly inclined to continue recommending device_type be present in these cases rather than relying solely on the name, or inventing a new way of marking these nodes.

Then there are the devices that do generally have 'compatible', but do have long established device_type values: "serial" and "network" are the main ones. We might be able to just drop the device_type values here and have nothing break. Unfortunatly, I rather suspect some drivers will check the device_type value, even though they shouldn't. Therefore I'm mildly inclined to at least suggest that device_type be optionally present for improved compatibility with legacy code.

Quoted 3 lines

The only situation where I can see it being appropriate to specify device_type is to work around older bindings that are ambiguous with their other properties.

Exactly right. The important thing is to always be aware than *any* presence of device_type in a flattened tree is basically a hack for compatibility with code expecting real-OF-like trees; it has no inherent purpose in a flattened tree.

Unfortunately getting people writing trees to realise this, when the property has that name, and appears freqeutnly in existing trees, seems to be a tricky problem.

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson