Re: [PATCH] Add MPC5200B base board mvBC-P
On Mon, Jul 07, 2008 at 08:12:11AM -0600, Grant Likely wrote: > On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz > <[EMAIL PROTECTED]> wrote: > > 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? That's correct. And more specially allows using it as a serial port using the OF defined method interface. > 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. > Does device_type indicated any other information other than firmware > driver interface? In theory, no. In practice... sort of, sometimes, maybe. > 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. > 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. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
On 7/7/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz > <[EMAIL PROTECTED]> wrote: > > 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. I experimented with this on my own trees. device_type = "serial"; Is current required on the boot console or it will disappear. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz <[EMAIL PROTECTED]> wrote: > 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. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
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
David Gibson schrieb:
> On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
>
>> 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]
>
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/mvbc-p.dts
>> @@ -0,0 +1,206 @@
>>
>
> [snip]
>
>> +[EMAIL PROTECTED] {
>> +device_type = "dma-controller";
>>
>
> No device_type here.
>
>
>> +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>;
>> +};
>> +
>> +[EMAIL PROTECTED] {
>> +compatible = "fsl,mpc5200-xlb";
>> +reg = <0x1f00 0x100>;
>> +};
>> +
>> +serial0: [EMAIL PROTECTED] {// PSC1
>> +device_type = "serial";
>> +compatible = "fsl,mpc5200-psc-uart";
>> +port-number = <0>;
>> +reg = <0x2000 0x100>;
>> +interrupts = <2 1 0>;
>> +interrupt-parent = <&mpc5200_pic>;
>> +};
>> +
>> +[EMAIL PROTECTED] {
>> +#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;
>> +};
>> +
>> +[EMAIL PROTECTED] {
>> +#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;
>> +};
>> +[EMAIL PROTECTED] {
>> +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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
> 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]
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mvbc-p.dts
> @@ -0,0 +1,206 @@
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "dma-controller";
No device_type here.
> + 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>;
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5200-xlb";
> + reg = <0x1f00 0x100>;
> + };
> +
> + serial0: [EMAIL PROTECTED] {// PSC1
> + device_type = "serial";
> + compatible = "fsl,mpc5200-psc-uart";
> + port-number = <0>;
> + reg = <0x2000 0x100>;
> + interrupts = <2 1 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + };
> +
> + [EMAIL PROTECTED] {
> + #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;
> + };
> +
> + [EMAIL PROTECTED] {
> + #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;
> + };
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5200-sram","sram";
> + reg = <0x8000 0x4000>;
> + };
> + };
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
On Sat, Jul 5, 2008 at 3:32 AM, André Schwarz <[EMAIL PROTECTED]> wrote: > 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. No, I'm *toying* with the idea, but I haven't decided yet. > > 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 ? hurumm... okay, leave it in. I suppose it isn't a risky thing to do. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
Grant,
thanks for the quick feedback - I'll try to improve.
Hopefully monday morning will be on time
Comments inline.
regards,
André
Grant Likely wrote:
On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
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
great.
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.
diff --git a/arch/powerpc/boot/dts/mvbc-p.dts b/arch/powerpc/boot/dts/mvbc-p.dts
new file mode 100644
index 000..90a2808
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -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,[EMAIL PROTECTED] {
+ 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 = <0x 0x>;
+ };
+
+ [EMAIL PROTECTED] {
+ #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.
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.
+ lpb {
+ compatible = "fsl,lpb";
You should also claim compatibility with "simple-bus" here.
ie: compatible = "fsl,lpb", "simple-bus";
ok.
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0xff80 0x0080>;
+ [EMAIL PROTECTED],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.
+ reg = <0 0 0x80>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <1>;
+ device-width = <1>;
+ [EMAIL PROTECTED] {
+ reg = <0x0 0x80>;
+ };
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.
+ [EMAIL PROTECTED] {
+ reg = <0x0 0x4>;
+ };
+ [EMAIL PROTECTED] {
+ reg = <0x4 0x1>;
+ };
+ [EMAIL PROTECTED] {
+ reg = <0x5 0x1>;
+ };
+ [EMAIL PROTECTED] {
+ re
Re: [PATCH] Add MPC5200B base board mvBC-P
On 7/4/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0xff80 0x0080>;
> > + [EMAIL PROTECTED],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"
>
> > + reg = <0 0 0x80>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + bank-width = <1>;
> > + device-width = <1>;
> > + [EMAIL PROTECTED] {
> > + reg = <0x0 0x80>;
> > + };
>
> I don't know if this is legal; to have overlapping flash sections (but
> I'm not a cfi-flash binding expert).
>
> > + [EMAIL PROTECTED] {
> > + reg = <0x0 0x4>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x4 0x1>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x5 0x1>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x6 0x4>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0xa0 0x6>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x10 0x30>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x40 0x3c>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x7c 0x1>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x7d 0x1>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x7e 0x1>;
> > + };
> > + [EMAIL PROTECTED] {
> > + reg = <0x7f 0x1>;
> > + };
>
> 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?
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
> 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
> 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).
> diff --git a/arch/powerpc/boot/dts/mvbc-p.dts
> b/arch/powerpc/boot/dts/mvbc-p.dts
> new file mode 100644
> index 000..90a2808
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mvbc-p.dts
> @@ -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,[EMAIL PROTECTED] {
> + 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 = <0x 0x>;
> + };
> +
> + [EMAIL PROTECTED] {
> + #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.
> + lpb {
> + compatible = "fsl,lpb";
You should also claim compatibility with "simple-bus" here.
ie: compatible = "fsl,lpb", "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0xff80 0x0080>;
> + [EMAIL PROTECTED],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"
> + reg = <0 0 0x80>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <1>;
> + device-width = <1>;
> + [EMAIL PROTECTED] {
> + reg = <0x0 0x80>;
> + };
I don't know if this is legal; to have overlapping flash sections (but
I'm not a cfi-flash binding expert).
> + [EMAIL PROTECTED] {
> + reg = <0x0 0x4>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x4 0x1>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x5 0x1>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x6 0x4>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0xa0 0x6>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x10 0x30>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x40 0x3c>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x7c 0x1>;
> + };
> + [EMAIL PROTECTED] {
> + reg = <0x7d 0x10
[PATCH] 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(-)
diff --git a/arch/powerpc/boot/dts/mvbc-p.dts b/arch/powerpc/boot/dts/mvbc-p.dts
new file mode 100644
index 000..90a2808
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -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,[EMAIL PROTECTED] {
+ 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 = <0x 0x>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc5200-immr";
+ ranges = <0 0xf000 0xc000>;
+ reg = <0xf000 0x0100>;
+ bus-frequency = <0>;
+ system-frequency = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5200-cdm";
+ reg = <0x200 0x38>;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ compatible = "fsl,mpc5200-pic";
+ reg = <0x500 0x80>;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = "fsl,mpc5200-gpt";
+ reg = <0x600 0x10>;
+ interrupts = <1 9 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5200-gpio";
+ reg = <0xb00 0x40>;
+ interrupts = <1 7 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5200-gpio-wkup";
+ reg = <0xc00 0x40>;
+ interrupts = <1 8 0 0 3 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
+ [EMAIL PROTECTED] {
+ 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>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5200-xlb";
+ reg = <0x1f00 0x100>;
+ };
+
+ serial0: [EMAIL PROTECTED] {// PSC1
+ device_type = "serial";
+ compatible = "fsl,mpc5200-psc-uart";
+ port-number = <0>;
+ reg = <0x2000 0x100>;
+ interrupts = <2 1 0>;
+
