* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <33AC4A3A-876A-4AF9-B851-928EE80A9D80@kernel.crashing.org>
On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
>
> On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
>
> > On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> >> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >>>>>
> >>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >>>>
> >>>> I believe in his latest patches he removed this part. The device
> >>>> trees
> >>>> were not included at all and he left this point open for
> >>>> discussion.
> >>>
> >>> That's correct.
> >>>
> >>> TBH, I think its wrong to keep them in the kernel source at all--
> >>> yes,
> >>> the same argument could be made for arch/powerpc/boot but that's
> >>> been
> >>> settled.
> >>
> >> Sorry, I have to disagree. We're talking about device tree _source_
> >> files here. I believe they should be included in the kernel source.
> >> Where that is, I don't have a particularly strong argument but they
> >> should be included.
> >
> > 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.
> >
> > powerpc/boot/dts makes a lot of sense to me.
>
> I like this location and agree that having them in tree makes sense.
> And putting them under boot isolates them from the kernel proper.
>
> The reason I see to having them in tree is to ensure proper version
> compatibility. This way there is no concern about which .dts version
> will work with which kernel. In the future we can always pull them
> out when things are more stable.
Hmm, that is a good reason...
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Grant Likely @ 2006-08-02 18:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802182319.GI17652@mag.az.mvista.com>
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
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-02 18:21 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154542161.5550.25.camel@localhost>
On Wed, Aug 02, 2006 at 01:09:21PM -0500, Matthew McClintock wrote:
> On Wed, 2006-08-02 at 09:38 -0700, Tom Rini wrote:
> > I'll throw in the caveat that I'm not 100% sure we're that stable yet,
> > but it certainly seems like it, at least for the overall portion where
> > you might really have incompatible trees. More or less complete (now
> > every device is described!) dts should be interchangable to the kernel
> > for the custom board X is just a little different from ref board Y
> > issues (and now, in theory, the Just Like A Sandpoint board, with a
> > correct dts will boot the 'sandpoint' kernel).
>
> 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.
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.
--
Tom Rini
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Matthew McClintock @ 2006-08-02 18:22 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802182226.GH17652@mag.az.mvista.com>
On Wed, 2006-08-02 at 11:22 -0700, 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?
>
One option is the *just* include the working tested DTB files in the
kernel source. That way there is a method to boot the boards. If you end
user wants to work with a different DTB they can go download the DTS
from another source (or optionally derive the DTS from the DTB) and make
changes.
That way we do not have to include 'dtc' in the kernel, and we still
have a valid DTB for every board included in the kernel. Also, there is
no reason to include both the DTB and DTS in the kernel considering they
can be easily derived from one another using 'dtc'
-Matthew
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Jon Loeliger @ 2006-08-02 18:23 UTC (permalink / raw)
To: Tom Rini; +Cc: Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <20060802182143.GP3075@smtp.west.cox.net>
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?
And yes, I'm trying to figure out where to _put_ the
8641 DTS file now too... :-)
jdl
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Jon Loeliger @ 2006-08-02 18:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <20060802182226.GH17652@mag.az.mvista.com>
On Wed, 2006-08-02 at 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?
I don't think we should keep pre-compiled DTB files
around anywhere. We don't keep a bunch of derived .o
files around, do we?
jdl
^ permalink raw reply
* Re: lockup during powersave on G3
From: marvin @ 2006-08-02 18:31 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1154510480.26242.18.camel@localhost.localdomain>
arrrr,
the lastest pull seems to have fixed the problem.
Le Wednesday 2 August 2006 11:21, Michael Ellerman a =C3=A9crit :
> On Wed, 2006-08-02 at 07:47 +0200, marvin wrote:
> > hi,
> >
> > since kernel 2.6.18-rc1 my b/w G3 mac locks up every time it goes into
> > powersave mode. Before trying to bisect, is there a candidate I can try
> > to revert?
>
> By "since" do you mean 2.6.18-rc1 worked and it's broken since then, or
> that something earlier worked and it's broken starting from 2.6.18-rc1?
>
> Ben's new irq stuff might be a candidate, that was a pretty big change.
commit 49b1e3ea19b1c95c2f012b8331ffb3b169e4c042
...
[POWERPC] Fix new interrupt code (MPIC detection)
[POWERPC] Fix new interrupt code (MPIC endianness)
...
could be the reason.
thanks!
marc
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154543116.19994.39.camel@cashmere.sps.mot.com>
On Wed, Aug 02, 2006 at 01:25:16PM -0500, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 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?
>
> I don't think we should keep pre-compiled DTB files
> around anywhere. We don't keep a bunch of derived .o
> files around, do we?
I agree.
Mark
^ permalink raw reply
* Re: [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Mark A. Greer @ 2006-08-02 18:31 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060802181514.GO3075@smtp.west.cox.net>
On Wed, Aug 02, 2006 at 11:15:14AM -0700, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 11:14:22AM -0700, Mark A. Greer wrote:
> > On Wed, Aug 02, 2006 at 09:19:34AM -0700, Tom Rini wrote:
> > > On Wed, Jul 19, 2006 at 04:14:21PM -0700, Mark A. Greer wrote:
> > >
> > > > This patch adds the firmware operations that support the DINK firmware
> > > > from Freescale.
> > >
> > > This isn't really DINK support (which would mean actually talking
> > > back/with DINK,
> >
> > You seem to be thinking that this is the final, end-all solution to
> > everything. It isn't. Its a step in the direction that we are trying
> > go (IIUC). dink.c is about the easiest one there will be. of.c has a
> > slightly more complicated fw_ops. We still need to figure out what uboot
> > needs and what PIBS needs and what...
>
> Right. I'm just saying that unless you're planning on making this talk
> with / use DINK (I swear, the DINK manual talks about this a bit, but
> I'm too lazy to look just this second), this isn't the DINK one, this is
> the (will be needed and used) bare metal one.
Ah, okay. Sure.
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-02 18:42 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154542975.5550.29.camel@localhost>
On Wed, Aug 02, 2006 at 01:22:55PM -0500, Matthew McClintock wrote:
> On Wed, 2006-08-02 at 11:22 -0700, 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?
> >
>
> One option is the *just* include the working tested DTB files in the
> kernel source. That way there is a method to boot the boards. If you end
> user wants to work with a different DTB they can go download the DTS
> from another source (or optionally derive the DTS from the DTB) and make
> changes.
It probably would be handier to have the dtb there but its a source
tree, so let's keep source there.
It'll just be a fact of life for a non-devtree fw platform user that
they need to find and use dtc and an attach tool to stick the dtb
onto the zImage.
> That way we do not have to include 'dtc' in the kernel, and we still
I don't think anyone was actually serious about including dtc in the kernel.
> have a valid DTB for every board included in the kernel. Also, there is
> no reason to include both the DTB and DTS in the kernel considering they
> can be easily derived from one another using 'dtc'
Mark
^ permalink raw reply
* 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
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