* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <528646bc0608021121l124cd3e8i14dfdfbf40272193@mail.gmail.com>
On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
> On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
> >On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> >> I have to second that opinion. The device tree is absolutely integral
> >> with the rest of the code/drivers needed to support a board. I say
> >> there are stronger arguments for keeping the dts files in the kernel
> >> source than there are for the boot wrapper.
> >
> >Well, the dts is no good to you without dtc so do we put dtc in the
> >kernel source tree too?
>
> I don't know; should we include gcc also?
>
> :p
Yep, my point.
I don't really have a problem with keeping known working dts files in
arch/powerpc/boot/dts. Perhaps a 1-1 match with files in
arch/powerpc/configs?
It would still be nice to have the dtc source, attach tool source, and,
if useful, a more exhaustive collection of dts files in one place.
benh? paulus?
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:51 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <200608021341.52084.bcook@bpointsys.com>
On Wed, Aug 02, 2006 at 01:41:51PM -0500, Brent Cook wrote:
> On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
> >
> > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > want the dts that makes that dtb to be in the same place?
> >
> > Mark
>
> There is precedence for this. Look at drivers/net/ixp2000/, it includes both
> the microengine source code, and the precompiled binary blob files (in case
> you do not have the required assembler.)
Interesting, but in our case everyone does have the compiler
(or at least with little effort they do).
Mark
^ permalink raw reply
* [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-02 18:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
As per list discussion, let's add device tree source files
under powerpc/boot/dts. If nothing else, it is a starting point.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 ++++++++++++++++++++++++++++++++
1 files changed, 338 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
new file mode 100644
index 0000000..55a8167
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -0,0 +1,338 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+
+/ {
+ model = "MPC8641HPCN";
+ compatible = "mpc86xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8641@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ linux,boot-cpu;
+ };
+ PowerPC,8641@1 {
+ device_type = "cpu";
+ reg = <1>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 40000000>; // 1G at 0x0
+ };
+
+ soc8641@f8000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 f8000000 00100000>;
+ reg = <f8000000 00100000>; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ linux,phandle = <24520>;
+ ethernet-phy@0 {
+ linux,phandle = <2452000>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@1 {
+ linux,phandle = <2452001>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@2 {
+ linux,phandle = <2452002>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@3 {
+ linux,phandle = <2452003>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ address = [ 00 E0 0C 00 73 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452000>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ address = [ 00 E0 0C 00 73 01 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452001>;
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ address = [ 00 E0 0C 00 02 FD ];
+ interrupts = <1F 2 20 2 21 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452002>;
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ address = [ 00 E0 0C 00 03 FD ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452003>;
+ };
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <40000>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <1c 2>;
+ interrupt-parent = <40000>;
+ };
+
+ pci@8000 {
+ compatible = "86xx";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ bus-range = <0 fe>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 e2000000 0 00100000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <40000>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x11 */
+ 8800 0 0 1 4d0 3 2
+ 8800 0 0 2 4d0 4 2
+ 8800 0 0 3 4d0 5 2
+ 8800 0 0 4 4d0 6 2
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 4d0 4 2
+ 9000 0 0 2 4d0 5 2
+ 9000 0 0 3 4d0 6 2
+ 9000 0 0 4 4d0 3 2
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 4d0 0 0
+ 9800 0 0 2 4d0 0 0
+ 9800 0 0 3 4d0 0 0
+ 9800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x14 */
+ a000 0 0 1 4d0 0 0
+ a000 0 0 2 4d0 0 0
+ a000 0 0 3 4d0 0 0
+ a000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 4d0 0 0
+ a800 0 0 2 4d0 0 0
+ a800 0 0 3 4d0 0 0
+ a800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 4d0 0 0
+ b000 0 0 2 4d0 0 0
+ b000 0 0 3 4d0 0 0
+ b000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 4d0 0 0
+ b800 0 0 2 4d0 0 0
+ b800 0 0 3 4d0 0 0
+ b800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x18 */
+ c000 0 0 1 4d0 0 0
+ c000 0 0 2 4d0 0 0
+ c000 0 0 3 4d0 0 0
+ c000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x19 */
+ c800 0 0 1 4d0 0 0
+ c800 0 0 2 4d0 0 0
+ c800 0 0 3 4d0 0 0
+ c800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1a */
+ d000 0 0 1 4d0 6 2
+ d000 0 0 2 4d0 3 2
+ d000 0 0 3 4d0 4 2
+ d000 0 0 4 4d0 5 2
+
+
+ /* IDSEL 0x1b */
+ d800 0 0 1 4d0 5 2
+ d800 0 0 2 4d0 0 0
+ d800 0 0 3 4d0 0 0
+ d800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1c */
+ e000 0 0 1 4d0 9 2
+ e000 0 0 2 4d0 a 2
+ e000 0 0 3 4d0 c 2
+ e000 0 0 4 4d0 7 2
+
+ /* IDSEL 0x1d */
+ e800 0 0 1 4d0 9 2
+ e800 0 0 2 4d0 a 2
+ e800 0 0 3 4d0 b 2
+ e800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1e */
+ f000 0 0 1 4d0 c 2
+ f000 0 0 2 4d0 0 0
+ f000 0 0 3 4d0 0 0
+ f000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1f */
+ f800 0 0 1 4d0 6 2
+ f800 0 0 2 4d0 0 0
+ f800 0 0 3 4d0 0 0
+ f800 0 0 4 4d0 0 0
+ >;
+ i8259@4d0 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ big-endian;
+ interrupts = <49 2>;
+ interrupt-parent = <40000>;
+ };
+
+ };
+ pic@40000 {
+ linux,phandle = <40000>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ interrupts = <
+ 10 2 11 2 12 2 13 2
+ 14 2 15 2 16 2 17 2
+ 18 2 19 2 1a 2 1b 2
+ 1c 2 1d 2 1e 2 1f 2
+ 20 2 21 2 22 2 23 2
+ 24 2 25 2 26 2 27 2
+ 28 2 29 2 2a 2 2b 2
+ 2c 2 2d 2 2e 2 2f 2
+ 30 2 31 2 32 2 33 2
+ 34 2 35 2 36 2 37 2
+ 38 2 39 2 2a 2 3b 2
+ 3c 2 3d 2 3e 2 3f 2
+ 48 1 49 2 4a 1
+ >;
+ interrupt-parent = <40000>;
+ };
+ };
+};
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Re: RFC: Location for Device Tree Sources?
From: Brent Cook @ 2006-08-02 18:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Guennadi Liakhovetski
In-Reply-To: <20060802182226.GH17652@mag.az.mvista.com>
On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
>
> Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> want the dts that makes that dtb to be in the same place?
>
> Mark
There is precedence for this. Look at drivers/net/ixp2000/, it includes both
the microengine source code, and the precompiled binary blob files (in case
you do not have the required assembler.)
- Brent
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-02 18:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <1154542988.19994.36.camel@cashmere.sps.mot.com>
On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
>
> > Yes, as I said, I'm not totally sure we're at the stable point right
> > now, but I think that we are. I'll add that maybe we need to think
> > about API changes and DTS format versions. To quote from my post..
> >
> > > > X bugs) or a change that requires a dts version bump.
> >
> > Now it sounds like the IRQ thing was an "Oops, we should have changed
> > the dts version" and bailed, noting what is wrong with the dts.
>
> This confuses me. There hasn't been a change in the DTS
> format at all. I've even updated the 8641HPCN DTS file
> across the IRQ updates and all is fine. Same (DTS) format
> both before and after the IRQ changes.
>
> What have I missed here?
Matthew said:
> The sandpoint (as far as I know) does not have a stable DTS. So in this
> case including the DTS in the kernel would reduce confusion. The same
> could be said for other boards where the DTS needed to be changed for
> the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
> sure how much longer we will run into this problem though.
Now, if we've had to change the contents of the DTS because of a kernel
change, I'd say the DTS format changed as when I say format I mean not
only layout and naming, but what the contents are supposed to contain.
And, so it's clear, I don't know if we're at the very stable format
(names/layout/content means...), but when we are at that point, what
Matthew noted should, IMHO, be a graceful (ie explained in the panic()
or something) death.
And, so it's clear, I think (and hope!) we all agree on that last part,
once we hit stability.
--
Tom Rini
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Josh Boyer @ 2006-08-02 19:03 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802184930.GN17652@mag.az.mvista.com>
On Wed, 2006-08-02 at 11:49 -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
> > On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
> > >On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
> > >> I have to second that opinion. The device tree is absolutely integral
> > >> with the rest of the code/drivers needed to support a board. I say
> > >> there are stronger arguments for keeping the dts files in the kernel
> > >> source than there are for the boot wrapper.
> > >
> > >Well, the dts is no good to you without dtc so do we put dtc in the
> > >kernel source tree too?
> >
> > I don't know; should we include gcc also?
> >
> > :p
>
> Yep, my point.
>
> I don't really have a problem with keeping known working dts files in
> arch/powerpc/boot/dts. Perhaps a 1-1 match with files in
> arch/powerpc/configs?
I like that idea very much. Actually that's what I thought were were
talking about in the first place.
>
> It would still be nice to have the dtc source, attach tool source, and,
> if useful, a more exhaustive collection of dts files in one place.
I also think that would be useful.
josh
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 19:24 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154544503.19994.42.camel@cashmere.sps.mot.com>
On Aug 2, 2006, at 1:48 PM, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> As per list discussion, let's add device tree source files
> under powerpc/boot/dts. If nothing else, it is a starting point.
>
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 +++++++++++++++++++++
> +++++++++++
> 1 files changed, 338 insertions(+), 0 deletions(-)
Do we want to go ahead and fix the mac address field having the wrong
name?
- kumar
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
> boot/dts/mpc8641_hpcn.dts
> new file mode 100644
> index 0000000..55a8167
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -0,0 +1,338 @@
> +/*
> + * MPC8641 HPCN Device Tree Source
> + *
> + * Copyright 2006 Freescale Semiconductor Inc.
> + *
> + * 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.
> + */
> +
> +
> +/ {
> + model = "MPC8641HPCN";
> + compatible = "mpc86xx";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #cpus = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8641@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>; // 32 bytes
> + i-cache-line-size = <20>; // 32 bytes
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>; // 33 MHz, from uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + 32-bit;
> + linux,boot-cpu;
> + };
> + PowerPC,8641@1 {
> + device_type = "cpu";
> + reg = <1>;
> + d-cache-line-size = <20>; // 32 bytes
> + i-cache-line-size = <20>; // 32 bytes
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>; // 33 MHz, from uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + 32-bit;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 40000000>; // 1G at 0x0
> + };
> +
> + soc8641@f8000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "soc";
> + ranges = <0 f8000000 00100000>;
> + reg = <f8000000 00100000>; // CCSRBAR 1M
> + bus-frequency = <0>;
> +
> + i2c@3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <2b 2>;
> + interrupt-parent = <40000>;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3100 100>;
> + interrupts = <2b 2>;
> + interrupt-parent = <40000>;
> + dfsrr;
> + };
> +
> + mdio@24520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> + linux,phandle = <24520>;
> + ethernet-phy@0 {
> + linux,phandle = <2452000>;
> + interrupt-parent = <40000>;
> + interrupts = <4a 1>;
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> + ethernet-phy@1 {
> + linux,phandle = <2452001>;
> + interrupt-parent = <40000>;
> + interrupts = <4a 1>;
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + ethernet-phy@2 {
> + linux,phandle = <2452002>;
> + interrupt-parent = <40000>;
> + interrupts = <4a 1>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + ethernet-phy@3 {
> + linux,phandle = <2452003>;
> + interrupt-parent = <40000>;
> + interrupts = <4a 1>;
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + address = [ 00 E0 0C 00 73 00 ];
> + interrupts = <1d 2 1e 2 22 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452000>;
> + };
> +
> + ethernet@25000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + address = [ 00 E0 0C 00 73 01 ];
> + interrupts = <23 2 24 2 28 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452001>;
> + };
> +
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <26000 1000>;
> + address = [ 00 E0 0C 00 02 FD ];
> + interrupts = <1F 2 20 2 21 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452002>;
> + };
> +
> + ethernet@27000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <27000 1000>;
> + address = [ 00 E0 0C 00 03 FD ];
> + interrupts = <25 2 26 2 27 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452003>;
> + };
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <2a 2>;
> + interrupt-parent = <40000>;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <1c 2>;
> + interrupt-parent = <40000>;
> + };
> +
> + pci@8000 {
> + compatible = "86xx";
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <8000 1000>;
> + bus-range = <0 fe>;
> + ranges = <02000000 0 80000000 80000000 0 20000000
> + 01000000 0 00000000 e2000000 0 00100000>;
> + clock-frequency = <1fca055>;
> + interrupt-parent = <40000>;
> + interrupts = <18 2>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> + /* IDSEL 0x11 */
> + 8800 0 0 1 4d0 3 2
> + 8800 0 0 2 4d0 4 2
> + 8800 0 0 3 4d0 5 2
> + 8800 0 0 4 4d0 6 2
> +
> + /* IDSEL 0x12 */
> + 9000 0 0 1 4d0 4 2
> + 9000 0 0 2 4d0 5 2
> + 9000 0 0 3 4d0 6 2
> + 9000 0 0 4 4d0 3 2
> +
> + /* IDSEL 0x13 */
> + 9800 0 0 1 4d0 0 0
> + 9800 0 0 2 4d0 0 0
> + 9800 0 0 3 4d0 0 0
> + 9800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x14 */
> + a000 0 0 1 4d0 0 0
> + a000 0 0 2 4d0 0 0
> + a000 0 0 3 4d0 0 0
> + a000 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x15 */
> + a800 0 0 1 4d0 0 0
> + a800 0 0 2 4d0 0 0
> + a800 0 0 3 4d0 0 0
> + a800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x16 */
> + b000 0 0 1 4d0 0 0
> + b000 0 0 2 4d0 0 0
> + b000 0 0 3 4d0 0 0
> + b000 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x17 */
> + b800 0 0 1 4d0 0 0
> + b800 0 0 2 4d0 0 0
> + b800 0 0 3 4d0 0 0
> + b800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x18 */
> + c000 0 0 1 4d0 0 0
> + c000 0 0 2 4d0 0 0
> + c000 0 0 3 4d0 0 0
> + c000 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x19 */
> + c800 0 0 1 4d0 0 0
> + c800 0 0 2 4d0 0 0
> + c800 0 0 3 4d0 0 0
> + c800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x1a */
> + d000 0 0 1 4d0 6 2
> + d000 0 0 2 4d0 3 2
> + d000 0 0 3 4d0 4 2
> + d000 0 0 4 4d0 5 2
> +
> +
> + /* IDSEL 0x1b */
> + d800 0 0 1 4d0 5 2
> + d800 0 0 2 4d0 0 0
> + d800 0 0 3 4d0 0 0
> + d800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x1c */
> + e000 0 0 1 4d0 9 2
> + e000 0 0 2 4d0 a 2
> + e000 0 0 3 4d0 c 2
> + e000 0 0 4 4d0 7 2
> +
> + /* IDSEL 0x1d */
> + e800 0 0 1 4d0 9 2
> + e800 0 0 2 4d0 a 2
> + e800 0 0 3 4d0 b 2
> + e800 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x1e */
> + f000 0 0 1 4d0 c 2
> + f000 0 0 2 4d0 0 0
> + f000 0 0 3 4d0 0 0
> + f000 0 0 4 4d0 0 0
> +
> + /* IDSEL 0x1f */
> + f800 0 0 1 4d0 6 2
> + f800 0 0 2 4d0 0 0
> + f800 0 0 3 4d0 0 0
> + f800 0 0 4 4d0 0 0
> + >;
> + i8259@4d0 {
> + clock-frequency = <0>;
> + interrupt-controller;
> + device_type = "interrupt-controller";
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + built-in;
> + compatible = "chrp,iic";
> + big-endian;
> + interrupts = <49 2>;
> + interrupt-parent = <40000>;
> + };
> +
> + };
> + pic@40000 {
> + linux,phandle = <40000>;
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <40000 40000>;
> + built-in;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
> + interrupts = <
> + 10 2 11 2 12 2 13 2
> + 14 2 15 2 16 2 17 2
> + 18 2 19 2 1a 2 1b 2
> + 1c 2 1d 2 1e 2 1f 2
> + 20 2 21 2 22 2 23 2
> + 24 2 25 2 26 2 27 2
> + 28 2 29 2 2a 2 2b 2
> + 2c 2 2d 2 2e 2 2f 2
> + 30 2 31 2 32 2 33 2
> + 34 2 35 2 36 2 37 2
> + 38 2 39 2 2a 2 3b 2
> + 3c 2 3d 2 3e 2 3f 2
> + 48 1 49 2 4a 1
> + >;
> + interrupt-parent = <40000>;
> + };
> + };
> +};
> --
> 2006_06_07.01.gittree_pull-dirty
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Kumar Gala @ 2006-08-02 19:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154545382.12757.1.camel@weaponx.rchland.ibm.com>
On Aug 2, 2006, at 2:03 PM, Josh Boyer wrote:
> On Wed, 2006-08-02 at 11:49 -0700, Mark A. Greer wrote:
>> On Wed, Aug 02, 2006 at 12:21:37PM -0600, Grant Likely wrote:
>>> On 8/2/06, Mark A. Greer <mgreer@mvista.com> wrote:
>>>> On Tue, Aug 01, 2006 at 09:20:52PM -0600, Grant Likely wrote:
>>>>> I have to second that opinion. The device tree is absolutely
>>>>> integral
>>>>> with the rest of the code/drivers needed to support a board. I
>>>>> say
>>>>> there are stronger arguments for keeping the dts files in the
>>>>> kernel
>>>>> source than there are for the boot wrapper.
>>>>
>>>> Well, the dts is no good to you without dtc so do we put dtc in the
>>>> kernel source tree too?
>>>
>>> I don't know; should we include gcc also?
>>>
>>> :p
>>
>> Yep, my point.
>>
>> I don't really have a problem with keeping known working dts files in
>> arch/powerpc/boot/dts. Perhaps a 1-1 match with files in
>> arch/powerpc/configs?
>
> I like that idea very much. Actually that's what I thought were were
> talking about in the first place.
>
>>
>> It would still be nice to have the dtc source, attach tool source,
>> and,
>> if useful, a more exhaustive collection of dts files in one place.
>
> I also think that would be useful.
While useful, I doubt its likely to happen. I forsee boards that
aren't in the kernel tree having their dts live in their private
worlds. Also tools like mkimage that come from u-boot will probably
still live with u-boot.
- kumar
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Adrian Cox @ 2006-08-02 19:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <027C3DD1-67E1-4CF2-B8B6-36CD1F09D1D2@kernel.crashing.org>
On Wed, 2006-08-02 at 08:32 -0500, Kumar Gala wrote:
> On Aug 2, 2006, at 3:25 AM, Adrian Cox wrote:
> > Is anybody else having problems with 32-bit SMP support in arch/
> > powerpc?
> > I'm using 2.6.17 as my current base, because I've not yet merged the
> > latest mpic changes.
> There are a few patches to prom.c that may help. I know I've run
> into this on other 32-bit systems booting from u-boot. These patches
> resolved my issue.
> * [PATCH] powerpc: Auto reserve of device tree blob
> * [POWERPC] Prevent duplicate lmb reservations for Device...
That was the problem. It now boots correctly, thanks.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Sergei Shtylyov @ 2006-08-02 19:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <9C1B15CC-6984-433D-8A1E-F856567B1AD2@kernel.crashing.org>
Hello.
Kumar Gala wrote:
> Do we want to go ahead and fix the mac address field having the wrong
> name?
If you mean "address" instead of "local-mac-address" then I guess
Documentation/powerpc/booting-without-of.txt should also be changed since it
has "address". And arch/powerpc/sysdev/fsl_soc.c as well..
>>+ ethernet@24000 {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+ device_type = "network";
>>+ model = "TSEC";
>>+ compatible = "gianfar";
>>+ reg = <24000 1000>;
>>+ address = [ 00 E0 0C 00 73 00 ];
>>+ interrupts = <1d 2 1e 2 22 2>;
>>+ interrupt-parent = <40000>;
>>+ phy-handle = <2452000>;
>>+ };
>>+
>>+ ethernet@25000 {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+ device_type = "network";
>>+ model = "TSEC";
>>+ compatible = "gianfar";
>>+ reg = <25000 1000>;
>>+ address = [ 00 E0 0C 00 73 01 ];
>>+ interrupts = <23 2 24 2 28 2>;
>>+ interrupt-parent = <40000>;
>>+ phy-handle = <2452001>;
>>+ };
>>+
>>+ ethernet@26000 {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+ device_type = "network";
>>+ model = "TSEC";
>>+ compatible = "gianfar";
>>+ reg = <26000 1000>;
>>+ address = [ 00 E0 0C 00 02 FD ];
>>+ interrupts = <1F 2 20 2 21 2>;
>>+ interrupt-parent = <40000>;
>>+ phy-handle = <2452002>;
>>+ };
>>+
>>+ ethernet@27000 {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+ device_type = "network";
>>+ model = "TSEC";
>>+ compatible = "gianfar";
>>+ reg = <27000 1000>;
>>+ address = [ 00 E0 0C 00 03 FD ];
>>+ interrupts = <25 2 26 2 27 2>;
>>+ interrupt-parent = <40000>;
>>+ phy-handle = <2452003>;
>>+ };
WBR, Sergei
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: David H. Lynch Jr. @ 2006-08-02 19:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060801100220.26176938@bob.dt.e-technik.uni-dortmund.de>
Benjamin Heyne wrote:
> Dear all,
> I am currently trying to get the 2.6.17.1 Linux kernel
> running on the Xilinx Virtex. I have the 2.4 kernel up
> and running - No problems there...
>
> But when using the 2.6 kernel (have copied xparameters file,
> patched for using TEMAC driver) with the same hardware configuration
> the following happens:
>
>
> loaded at: 00400000 0061813C
> board data at: 00616124 0061613C
> relocated to: 00405148 00405160
> zimage at: 0040585D 00615F42
> avail ram: 00619000 20000000
>
> Linux/PPC load: console=ttyS0,9600.....
>
> Uncompressing Linux...inflate returned FFFFFFFB
> exit
>
>
Zlib was upgraded with 2.6.17. The updated Zlib is broken on ppc32.
I am pretty certain it is fixed in 2.6.18-rc3
> Now, I am not really sure where to start searching for the bug
> (I just want to implement some drivers - not the kernel itself ;-).
> The zImage.elf file is about 2MB large. Did anyone encounter
> a similar error? Does anyone have some hints where to
> look at for debugging, or what might be wrong?
>
> Thanks in advance
> Best regards
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Kumar Gala @ 2006-08-02 20:06 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802185728.GQ3075@smtp.west.cox.net>
On Aug 2, 2006, at 1:57 PM, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
>> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
>>
>>> Yes, as I said, I'm not totally sure we're at the stable point right
>>> now, but I think that we are. I'll add that maybe we need to think
>>> about API changes and DTS format versions. To quote from my post..
>>>
>>>>> X bugs) or a change that requires a dts version bump.
>>>
>>> Now it sounds like the IRQ thing was an "Oops, we should have
>>> changed
>>> the dts version" and bailed, noting what is wrong with the dts.
>>
>> This confuses me. There hasn't been a change in the DTS
>> format at all. I've even updated the 8641HPCN DTS file
>> across the IRQ updates and all is fine. Same (DTS) format
>> both before and after the IRQ changes.
>>
>> What have I missed here?
>
> Matthew said:
>> The sandpoint (as far as I know) does not have a stable DTS. So in
>> this
>> case including the DTS in the kernel would reduce confusion. The same
>> could be said for other boards where the DTS needed to be changed for
>> the IRQ rework. The old DTS will no longer boot the new kernels.
>> I'm not
>> sure how much longer we will run into this problem though.
>
> Now, if we've had to change the contents of the DTS because of a
> kernel
> change, I'd say the DTS format changed as when I say format I mean not
> only layout and naming, but what the contents are supposed to contain.
>
> And, so it's clear, I don't know if we're at the very stable format
> (names/layout/content means...), but when we are at that point, what
> Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> or something) death.
>
> And, so it's clear, I think (and hope!) we all agree on that last
> part,
> once we hit stability.
Agree about the comments related to the stability of the API, I just
dont think we are there yet. We should revisit the issue when we
removed arch/ppc, until that point I would say things are up in the air.
For example, we still haven't closed on CPM descriptions and I'm sure
we will go through several iterations before we get it right. For
more standard things like uart's, ethernet, pci we have the OF specs
to model off of and are probably pretty stable.
Additionally, Ben and I have talked about making macro's in the dts's
so we can build up a board or SOC description from standard building
blocks so people dont get the simple things wrong.
- kumar
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 20:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <44D0FDF3.4020401@ru.mvista.com>
On Aug 2, 2006, at 2:33 PM, Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
>> Do we want to go ahead and fix the mac address field having the
>> wrong name?
>
> If you mean "address" instead of "local-mac-address" then I
> guess Documentation/powerpc/booting-without-of.txt should also be
> changed since it has "address". And arch/powerpc/sysdev/fsl_soc.c
> as well..
Yeah, fsl_soc.c should be updated to support both forms for a period
of time.
- kumar
>>> + ethernet@24000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "network";
>>> + model = "TSEC";
>>> + compatible = "gianfar";
>>> + reg = <24000 1000>;
>>> + address = [ 00 E0 0C 00 73 00 ];
>>> + interrupts = <1d 2 1e 2 22 2>;
>>> + interrupt-parent = <40000>;
>>> + phy-handle = <2452000>;
>>> + };
>>> +
>>> + ethernet@25000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "network";
>>> + model = "TSEC";
>>> + compatible = "gianfar";
>>> + reg = <25000 1000>;
>>> + address = [ 00 E0 0C 00 73 01 ];
>>> + interrupts = <23 2 24 2 28 2>;
>>> + interrupt-parent = <40000>;
>>> + phy-handle = <2452001>;
>>> + };
>>> +
>>> + ethernet@26000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "network";
>>> + model = "TSEC";
>>> + compatible = "gianfar";
>>> + reg = <26000 1000>;
>>> + address = [ 00 E0 0C 00 02 FD ];
>>> + interrupts = <1F 2 20 2 21 2>;
>>> + interrupt-parent = <40000>;
>>> + phy-handle = <2452002>;
>>> + };
>>> +
>>> + ethernet@27000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "network";
>>> + model = "TSEC";
>>> + compatible = "gianfar";
>>> + reg = <27000 1000>;
>>> + address = [ 00 E0 0C 00 03 FD ];
>>> + interrupts = <25 2 26 2 27 2>;
>>> + interrupt-parent = <40000>;
>>> + phy-handle = <2452003>;
>>> + };
>
> WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-02 20:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <9C1B15CC-6984-433D-8A1E-F856567B1AD2@kernel.crashing.org>
On Wed, 2006-08-02 at 14:24, Kumar Gala wrote:
> On Aug 2, 2006, at 1:48 PM, Jon Loeliger wrote:
>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> > ---
> >
> > As per list discussion, let's add device tree source files
> > under powerpc/boot/dts. If nothing else, it is a starting point.
> >
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 +++++++++++++++++++++
> > +++++++++++
> > 1 files changed, 338 insertions(+), 0 deletions(-)
>
> Do we want to go ahead and fix the mac address field having the wrong
> name?
>
> - kumar
Yeah, we have lined up Matt to make a comprehensive
update for this. Can we take my patch as-is? Matt will
follow up with a clean sweep, including fsl_socl.c, to
fix it all in one swell foop.
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
> > boot/dts/mpc8641_hpcn.dts
> > new file mode 100644
> > index 0000000..55a8167
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -0,0 +1,338 @@
> > +/*
> > + * MPC8641 HPCN Device Tree Source
> > + *
Any chance we can avoid quoting-back the largely irrelevant
parts of a post like this in the future?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Hollis Blanchard @ 2006-08-02 19:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154544503.19994.42.camel@cashmere.sps.mot.com>
On Wed, 2006-08-02 at 13:48 -0500, Jon Loeliger wrote:
>
> + PowerPC,8641@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>; // 32 bytes
> + i-cache-line-size = <20>; // 32 bytes
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>; // 33 MHz,
> from uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + 32-bit;
> + linux,boot-cpu;
> + };
I need to do something similar for Xen, so I was curious: I guess the
preferred way for runtime software to fill in values is by *overwriting*
bogus values inserted at compile time?
The other alternative would be for the runtime code to insert new
properties (presumably via memmove()), but overwriting definitely seems
simpler.
-Hollis
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Hollis Blanchard @ 2006-08-02 19:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <9C1B15CC-6984-433D-8A1E-F856567B1AD2@kernel.crashing.org>
On Wed, 2006-08-02 at 14:24 -0500, Kumar Gala wrote:
>
> Do we want to go ahead and fix the mac address field having the wrong
> name?
Yes please.
-Hollis
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 20:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154549483.19994.46.camel@cashmere.sps.mot.com>
On Aug 2, 2006, at 3:11 PM, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 14:24, Kumar Gala wrote:
>> On Aug 2, 2006, at 1:48 PM, Jon Loeliger wrote:
>>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>>> ---
>>>
>>> As per list discussion, let's add device tree source files
>>> under powerpc/boot/dts. If nothing else, it is a starting point.
>>>
>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 +++++++++++++++++++++
>>> +++++++++++
>>> 1 files changed, 338 insertions(+), 0 deletions(-)
>>
>> Do we want to go ahead and fix the mac address field having the wrong
>> name?
>>
>> - kumar
>
>
> Yeah, we have lined up Matt to make a comprehensive
> update for this. Can we take my patch as-is? Matt will
> follow up with a clean sweep, including fsl_socl.c, to
> fix it all in one swell foop.
I think this is one that is clearly something that should be fixed
before acceptance. Since we are talking about a dozen lines of
modifications. Especially since at this point having the .dts in the
tree doesn't really effect anything inside the kernel tree.
- kumar
>>> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
>>> boot/dts/mpc8641_hpcn.dts
>>> new file mode 100644
>>> index 0000000..55a8167
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> @@ -0,0 +1,338 @@
>>> +/*
>>> + * MPC8641 HPCN Device Tree Source
>>> + *
>
> Any chance we can avoid quoting-back the largely irrelevant
> parts of a post like this in the future?
>
> Thanks,
> jdl
>
>
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-02 20:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <BFD18279-7617-4F50-BB22-21A46C65FD50@kernel.crashing.org>
On Wed, 2006-08-02 at 15:30, Kumar Gala wrote:
> > Yeah, we have lined up Matt to make a comprehensive
> > update for this. Can we take my patch as-is? Matt will
> > follow up with a clean sweep, including fsl_socl.c, to
> > fix it all in one swell foop.
>
> I think this is one that is clearly something that should be fixed
> before acceptance. Since we are talking about a dozen lines of
> modifications. Especially since at this point having the .dts in the
> tree doesn't really effect anything inside the kernel tree.
>
> - kumar
On the other hand, this matches what the kernel implements
today, and is already in use by several people around the
world. It _does_ have an affect and is based on things
inside the kernel tree today as it is.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Mark A. Greer @ 2006-08-02 20:49 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154548217.32357.27.camel@basalt.austin.ibm.com>
On Wed, Aug 02, 2006 at 02:50:17PM -0500, Hollis Blanchard wrote:
> On Wed, 2006-08-02 at 13:48 -0500, Jon Loeliger wrote:
> >
> > + PowerPC,8641@0 {
> > + device_type = "cpu";
> > + reg = <0>;
> > + d-cache-line-size = <20>; // 32 bytes
> > + i-cache-line-size = <20>; // 32 bytes
> > + d-cache-size = <8000>; // L1, 32K
> > + i-cache-size = <8000>; // L1, 32K
> > + timebase-frequency = <0>; // 33 MHz,
> > from uboot
> > + bus-frequency = <0>; // From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + linux,boot-cpu;
> > + };
>
> I need to do something similar for Xen, so I was curious: I guess the
> preferred way for runtime software to fill in values is by *overwriting*
> bogus values inserted at compile time?
>
> The other alternative would be for the runtime code to insert new
> properties (presumably via memmove()), but overwriting definitely seems
> simpler.
Two reasons you may want to overwrite instead of insert a new one (at
least for now):
1) Strictly opinion: Its nice to be able to see the completely
functional tree and not one that's missing a critical property
that is magically inserted behind the scenes.
2) Strictly practical for now: If you plan on using a zImage with
the fdt patches that are being discussed right now, the fdt code
doesn't currently support inserting a new property, only modifying an
existing one. Patches always welcome though! :)
Mark
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 20:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154550970.19994.57.camel@cashmere.sps.mot.com>
On Aug 2, 2006, at 3:36 PM, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 15:30, Kumar Gala wrote:
>
>>> Yeah, we have lined up Matt to make a comprehensive
>>> update for this. Can we take my patch as-is? Matt will
>>> follow up with a clean sweep, including fsl_socl.c, to
>>> fix it all in one swell foop.
>>
>> I think this is one that is clearly something that should be fixed
>> before acceptance. Since we are talking about a dozen lines of
>> modifications. Especially since at this point having the .dts in the
>> tree doesn't really effect anything inside the kernel tree.
>>
>> - kumar
>
> On the other hand, this matches what the kernel implements
> today, and is already in use by several people around the
> world. It _does_ have an affect and is based on things
> inside the kernel tree today as it is.
True, but the people that are running this dont really care if the
dts is in the kernel or not. I think having an error in the kernel
tree that we know about is more of an issue. Its something we all
agree needs to be fixed.
Here is the code modification to fsl_soc.c, I'm sure we can get this
fixed push into 2.6.18 if desired.
if(mac_addr = get_property(np, "address", NULL))
memcpy(gfar_data.mac_addr, mac_addr, 6);
if(mac_addr = get_property(np, "local-mac-address", NULL);
memcpy(gfar_data.mac_addr, mac_addr, 6);
- kumar
^ permalink raw reply
* [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-02 20:59 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
The following is a patch which creates a new target called 'cuImage'. It
is designed to correctly package the kernel along with the
'arch/powerpc/boot' wrapper code into a uImage to be loaded and started
by U-Boot.
The purpose of this target is to allow boards with older versions of
U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
kernels. The bootwrapper will begin execution and can correctly setup a
flat device tree based on values passed in the bd_t structure, something
old versions of U-Boot are not capable of.
One might ask why not just use the 'bootelf' command in u-boot. Well,
not all boards have that option compiled in, and some other boards might
not even have access to the console. Also, the bd_t structure is not
passed from U-Boot when using the bootelf command so we would have no
method to correctly fill in values in the device tree. This would
theoretically allow an old board to start a new kernel without access to
the console if required.
Currently the zImage looks like this:
---------------------------------
- _start -
- boot wrapper code -
- ----------------------------- -
- - device tree - -
- ----------------------------- -
- ----------------------------- -
- - - -
- - compressed - -
- - kernel image - -
- - - -
- ----------------------------- -
---------------------------------
And the new cuImage will look like this:
-------------------------------------
- compressed uImage - -
- ------------------------------- - -
- - _start - - -
- - boot wrapper code - - -
- - ----------------------------- - -
- - - device tree - - -
- - ----------------------------- - -
- - ----------------------------- - -
- - - - - -
- - - UNcompressed - - -
- - - kernel image - - -
- - - - - -
- - ----------------------------- - -
- --------------------------------- -
-------------------------------------
-Matthew
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..2d2c39a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -96,11 +96,21 @@ config GENERIC_TBSYNC
default n
config DEFAULT_UIMAGE
- bool
+ bool "Set uImage to be the default build target"
help
Used to allow a board to specify it wants a uImage built by default
default n
+config UIMAGELOADADDR
+ hex "Set the uImage load address"
+ default 400000
+ depends on DEFAULT_UIMAGE
+
+config UIMAGEENTRY
+ hex "Set the uImage entry address"
+ default 400010
+ depends on DEFAULT_UIMAGE
+
menu "Processor support"compatibility
choice
prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..eefbe16 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
defaultimage-y := zImage
defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..72e8ad8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,7 +23,8 @@ # in the toplevel makefile.
HOSTCC := gcc
BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
- $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+ $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+ -fno-schedule-insns -fno-schedule-insns2 -fno-inline
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
OBJCOPYFLAGS := contents,alloc,load,readonly,data
OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
@@ -198,10 +199,18 @@ cmd_mygzip = gzip -f -9 < $< > $@.$$$$ &
quiet_cmd_objbin = OBJCOPY $@
cmd_objbin = $(OBJCOPY) -O binary $< $@
+ifndef CONFIG_UIMAGELOADADDR
+CONFIG_UIMAGELOADADDR = 00000000
+endif
+
+ifndef CONFIG_UIMAGEENTRY
+CONFIG_UIMAGEENTRY = 00000000
+endif
+
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel
\
- -C gzip -a 00000000 -e 00000000 -n
'Linux-$(KERNELRELEASE)' \
- -d $< $@
+ -C gzip -a $(CONFIG_UIMAGELOADADDR) -e $(CONFIG_UIMAGEENTRY) \
+ -n 'Linux-$(KERNELRELEASE)' -d $< $@
MKIMAGE := $(srctree)/scripts/mkuboot.sh
targets += uImage
@@ -223,3 +232,40 @@ install: $(CONFIGURE) $(BOOTIMAGE)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_addsection_cuimage = ADDSEC $@
+ cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+ --add-section=.kernel:vmlinux.elf=vmlinux \
+ --set-section-flags=.kernel:vmlinux.elf=$(OBJCOPYFLAGS)
+
+$(obj)/kernel-compat.c:
+ @touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c vmlinux
+ $(call if_changed_dep,bootcc)
+ $(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+ $(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+ $(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+ $(call if_changed,mygzip)
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+ $(Q)rm -f $@
+ $(call cmd,uimage)
+ @echo -n ' Image: $@ '
+ @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage
+
+
^ permalink raw reply related
* RE: Sloooooowwww CFI Flash programming
From: Frank @ 2006-08-02 22:12 UTC (permalink / raw)
To: Franca, Jose Filipe (ext), linuxppc-dev
In-Reply-To: <4051B1A83682514BA8529BCADDA45F086EE65A@PTLISI050MSX.PT001.SIEMENS.NET>
--- "Franca, Jose Filipe (ext)" <jose.franca.ext@siemens.com>
wrote:
> That is implemented in the 2.6 kernels. Are you sugesting a
> merge with
> 2.6 code? Or there is a patch that implements that in 2.4
> kernels?
>
> -----Original Message-----
> From: Frank [mailto:frannk_m1@yahoo.com]
> Sent: quarta-feira, 2 de Agosto de 2006 17:41
> To: Franca, Jose Filipe (ext); linuxppc-dev@ozlabs.org
> Subject: Re: Sloooooowwww CFI Flash programming
Look around, I've used buffered writes on a 2.4.25 kernel...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-02 22:33 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154552346.5550.51.camel@localhost>
In message <1154552346.5550.51.camel@localhost> you wrote:
>
> And the new cuImage will look like this:
>
> -------------------------------------
> - compressed uImage - -
> - ------------------------------- - -
> - - _start - - -
> - - boot wrapper code - - -
> - - ----------------------------- - -
> - - - device tree - - -
> - - ----------------------------- - -
> - - ----------------------------- - -
> - - - - - -
> - - - UNcompressed - - -
> - - - kernel image - - -
> - - - - - -
> - - ----------------------------- - -
> - --------------------------------- -
> -------------------------------------
Please explain.
In my understanding, an "uImage" file is a image consisting of an
U-Boot header (64 bytes) followed by an (compressed or uncompressed)
Linux kernel image.
So what do you mean by "compressed uImage"? If you take an "uImage"
file according to above definition and compress it, it will not be
recognized by U-Boot.
And why do you need a second, "UNcompressed kernel image" in your
setup? I must be missing something, because including *two* kernel
images makes no sense to me, and I don't understand why you would
want to insist of an "UNcompressed" image...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1st Old Man: Gee, its windy today.
2nd Old Man: No it's not... it's Thursday.
3rd Old Man: Yeh, me too. Let's go for a beer.
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Tom Rini @ 2006-08-03 0:30 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154552346.5550.51.camel@localhost>
On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:
[snip]
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 01667d1..eefbe16 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -141,12 +141,13 @@ # Default to zImage, override when neede
> defaultimage-y := zImage
> defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
> defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
> +defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
This means we never default to a regular 'uImage', and should either
modify the existing line, or a DEFAULT_CUIMAGE. No preference/etc, just
noting.
--
Tom Rini
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-03 0:35 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20060802185153.GO17652@mag.az.mvista.com>
On Wed, Aug 02, 2006 at 11:51:53AM -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 01:41:51PM -0500, Brent Cook wrote:
> > On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
> > >
> > > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > > want the dts that makes that dtb to be in the same place?
> > >
> > > Mark
> >
> > There is precedence for this. Look at drivers/net/ixp2000/, it includes both
> > the microengine source code, and the precompiled binary blob files (in case
> > you do not have the required assembler.)
>
> Interesting, but in our case everyone does have the compiler
> (or at least with little effort they do).
There are a few other cases of this, with the intention that if you're
mucking with these files you can regenerate. But we're just talking
about the blob in this part of the thread..
--
Tom Rini
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox