* Re: [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
From: Josh Boyer @ 2007-09-20 18:51 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46F2BFFA.1060203@ru.mvista.com>
On Thu, 20 Sep 2007 22:46:18 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Valentine Barshak wrote:
> > David Gibson wrote:
> >> On Tue, Sep 18, 2007 at 09:29:13PM +0400, Valentine Barshak wrote:
> >>> According to PowerPC 440EPx documentation,
> >>> MAL0 is comprised of four channels (two transmit and two receive).
> >>> Each channel is dedicated to one of two EMAC cores.
> >>> This patch fixes Sequoia DTS MAL0 entry and EMAC entries,
> >>> assigning correct channel numbers to EMACs.
> >>
> >> Hrm.. did they change the EMAC in 440EPx to only use one MAL
> >> tx-channel? All the older ones could use two (for no readily apparent
> >> reason, IMO).
> >>
> > Yes, they did.
> > Just 1 tx and 1 rx-channel per EMAC. Just 2 bits to select channels,
> > while all other bits in MAL registers are reserved.
> > I'm not sure why they did it (possible bus bandwidth problems), but it's
> > impossible to set more than 1 rx/tx channel for each EMAC in 440EPx.
>
> Josh, David, is this patch OK?
Yeah. I applied it to my tree and asked Paul to pull. Same for the
Bamboo one.
josh
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
From: Valentine Barshak @ 2007-09-20 18:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <46F10478.1080506@ru.mvista.com>
Valentine Barshak wrote:
> David Gibson wrote:
>> On Tue, Sep 18, 2007 at 09:29:13PM +0400, Valentine Barshak wrote:
>>> According to PowerPC 440EPx documentation,
>>> MAL0 is comprised of four channels (two transmit and two receive).
>>> Each channel is dedicated to one of two EMAC cores.
>>> This patch fixes Sequoia DTS MAL0 entry and EMAC entries,
>>> assigning correct channel numbers to EMACs.
>>
>> Hrm.. did they change the EMAC in 440EPx to only use one MAL
>> tx-channel? All the older ones could use two (for no readily apparent
>> reason, IMO).
>>
> Yes, they did.
> Just 1 tx and 1 rx-channel per EMAC. Just 2 bits to select channels,
> while all other bits in MAL registers are reserved.
> I'm not sure why they did it (possible bus bandwidth problems), but it's
> impossible to set more than 1 rx/tx channel for each EMAC in 440EPx.
Josh, David, is this patch OK?
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix QEIC->MPIC cascading
From: Scott Wood @ 2007-09-20 18:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46F2B8FD.7040501@freescale.com>
Timur Tabi wrote:
> Anton Vorontsov wrote:
>
>> I don't know (didn't look) why this works for 83xx w/o ack()...
>> maybe IPIC don't need this. Or maybe there is a bug hiding.
>
> Scott W told me that me that the IPIC doesn't have the concept of EOI ack. It
> just has IRQ masks.
And the IRQ will be masked at the QEIC while being processed. Doing it
this way allows another QE interrupt to come through while the first is
being serviced.
It might make sense on MPIC to ack after masking at the QEIC, for this
reason.
-Scott
^ permalink raw reply
* Re: device tree question
From: Scott Wood @ 2007-09-20 18:31 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0709201053s3643523eid42ea60dae53af84@mail.gmail.com>
Alan Bennett wrote:
> Ok, making progress on the ep8248 / devtrees, etc...
>
> But I'm not getting any output on the serial and my log_buf is pretty
> clean. Without console; what's the best way to figure out why I'm not
> getting any output on my SMC1 serial port (using u-boot , not planetcore)?
U-boot locates the SMC1 registers in a different place than planetcore;
SMC1's reg property should be <11a80 20 0 40>, and the cpm's reg
property should be <119c0 30 80 1f80>.
> CS: chipselect {
> compatible = "fsl,ep8248e-chipselect",
> "fsl,mpc8248-chipselect",
> "fsl,pq2-chipselect";
> #address-cells = <2>;
> #size-cells = <1>;
> fsl,ctrl = <&CSCTRL>;
This has changed, and I haven't yet updated ep8248e. The above should be:
localbus@f0010100 {
compatible = "fsl,mpc8248-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
You'll also need to update the bus probe matches in ep8248e.c.
> ranges = <0 0 f8000000 07f00000
> 0 1 fff00000 00080000
> 0 2 fff80000 00080000
This is wrong; the first cell is the chipselect, and the second cell is
the offset in bytes. I rather doubt the second flash begins at byte 1
and the third at byte 2. :-)
> 1 0 e4000000 00008000
> 2 0 d0000000 08000000>;
> /* F800_0000 -> FFF0_0000 */
> flash@0,0 {
> compatible = "cfi-flash";
> reg = <0 0 7F00000>;
> probe-type = "CFI";
> bank-width = <4>;
> };
This is a mix of the new and old flash bindings (again, I haven't yet
updated ep8248e). Look at the other dts files such as mpc8272ads and
ep88xc for assistance.
> /* F400_0000 */
> bcsr@1,0 {
It says e4000000 in ranges...
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <1 0 10>;
> compatible = "fsl,ep8248e-bcsr";
> ranges;
>
> mdio {
> device_type = "mdio";
> compatible = "fsl,ep8248e-mdio-bitbang";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1 8 1>;
>
> PHY0: ethernet-phy@0 {
> interrupt-parent = <&PIC>;
> reg = <0>;
> device_type = "ethernet-phy";
> };
>
> PHY1: ethernet-phy@1 {
> interrupt-parent = <&PIC>;
> reg = <1>;
> device_type = "ethernet-phy";
> };
> };
> };
> /* D000_0000 -> D7FF_FFFF */
> flash@2,0 {
> compatible = "cfi-flash";
> reg = <0 0 08000000>;
reg should be <2 0, not <0 0.
> soc@f0000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> device_type = "soc";
> compatible = "fsl,mpc8248", "fsl,pq2-soc";
> ranges = <00000000 f0000000 00053000>;
You need a reg property here until the kernel uses ranges; see the
mpc8272ads dts in my tree.
> CSCTRL: chipselect {
> compatible = "fsl,mpc8248-chipselect-ctrl",
> "fsl,pq2-chipselect-ctrl";
> reg = <10100 40>;
> fsl,bus = <&CS>;
> };
This can go away.
-Scott
^ permalink raw reply
* Re: [PATCH] PowerPC: add setup_cpu for 44x for processor-specific init
From: Valentine Barshak @ 2007-09-20 18:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, miltonm, david
In-Reply-To: <20070920131336.58df01e7@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 20 Sep 2007 21:55:58 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> This adds cpu_setup functionality to PowerPC 44x platform.
>> The cpu_setup callback is invoked by head_32 code and
>> the identify_cpu() function at early init and is used to
>> initialize FPU on 440EP(x) processors. The FPU initialization
>> was previously done in head_44x.S. Also a workaround for
>> the incorrect write to DDR SDRAM 440EPx/440GRx errata added.
>> Data can be written to wrong address in SDRAM when write
>> pipelining is enabled on plb0. The setup_cpu function
>> for these processors disables write pipelining.
>
> Wow, you're fast ;)
>
> I'd like to see this split up a bit so there's not so much in one
> patch. Essentially, introduce cpu_setup_44x.S, move the FPU init to
> use it, and then add the PLB workaround.
OK
>
> I still need to look at the code too :)
sure :)
>
> josh
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix QEIC->MPIC cascading
From: Timur Tabi @ 2007-09-20 18:16 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070920174159.GA10765@localhost.localdomain>
Anton Vorontsov wrote:
> I don't know (didn't look) why this works for 83xx w/o ack()...
> maybe IPIC don't need this. Or maybe there is a bug hiding.
Scott W told me that me that the IPIC doesn't have the concept of EOI ack. It
just has IRQ masks.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Valentine Barshak @ 2007-09-20 18:13 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <20070920130255.0f6855e1@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 20 Sep 2007 12:32:56 -0500 (CDT)
> Milton Miller <miltonm@bga.com> wrote:
>
>> On Fri Sep 21 02:56:32 EST 2007, Valentine Barshak wrote:
>>> Josh Boyer wrote:
>>>> On Wed, 19 Sep 2007 14:30:24 -0500
>>>> Olof Johansson <olof at lixom.net> wrote:
>>>>
>>>>> On Wed, Sep 19, 2007 at 09:19:47PM +0200, Stefan Roese wrote:
>>>>>> Hi Valentine,
>>>>>>
>>>>>> On Wednesday 19 September 2007, Valentine Barshak wrote:
>>>>>>> Disabling write pipelining really helps.
>>>>>>> Josh, David, what is the right place to put this workaround to?
>>>>>>>
>>>>>>> Is it OK to do mtdcr(PLB4A0_ACR, mfdcr(PLB4A0_ACR) & ~PLB4_WRP); in
>>>>>>> arch/powerpc/boot/cuboot-sequoia.c:sequoia_fixups()?
>>>>>>> or
>>>>>>> should this be done in
>>>>>>> arch/powerpc/platforms/44x/sequoia.c:sequoia_setup_arch()
>>>>>>> with dcr_map, dcr_read/write stuff?
>>>>>> I vote for putting it into sequoia.c, since it's very likely to happen that
>>>>>> Sequoia will at one point be booted without the bootwrapper. Or perhaps it
>>>>>> should go into some common code checking the PVR and disabling it when this
>>>>>> 440EPx/GRx is detected, since all those boards are affected.
>>>>> This is what we have setup_cpu functions in the cpu table for. Please
>>>>> put it there instead of in board code.
>>>> Yes, agreed.
>>> I was thinking about it. Looks like it's the best place, but the code
>>> that actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
>>> cpu_setup functions are defined for ppc32 processors.
>>> Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>> head_32.S calls call_setup_cpu in misc_32.S to call the cpu setup functon.
>>
>> Note that these functions are called before the kernel is copied down to
>> 0, so on ppc32 you will need the PTRRELOC type stuff. Also the callsite
>> implies that the cpu number is available in r24, which may or may not be
>> true when called from C.
>>
>> Its probably easier to just call call_setup_cpu in the other 32 bit
>> head_xxx files.
>
> Hm. I'll have to see how well that would work for 4xx. Seems 8xx and
> FSL BookE are in a similar situation.
I started preparing the patch after Olof's "take out the ifdef" :)
I've tested it on 4xx. seems to work fine. FPU works OK and EPX/GRX
workaround is fine also, but it has to be tested on 8xx and fsl.
Adding call_setup_cpu to head_44x is no problem.
>
> josh
^ permalink raw reply
* Re: [PATCH] PowerPC: add setup_cpu for 44x for processor-specific init
From: Josh Boyer @ 2007-09-20 18:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, miltonm, david
In-Reply-To: <20070920175558.GA3191@ru.mvista.com>
On Thu, 20 Sep 2007 21:55:58 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> This adds cpu_setup functionality to PowerPC 44x platform.
> The cpu_setup callback is invoked by head_32 code and
> the identify_cpu() function at early init and is used to
> initialize FPU on 440EP(x) processors. The FPU initialization
> was previously done in head_44x.S. Also a workaround for
> the incorrect write to DDR SDRAM 440EPx/440GRx errata added.
> Data can be written to wrong address in SDRAM when write
> pipelining is enabled on plb0. The setup_cpu function
> for these processors disables write pipelining.
Wow, you're fast ;)
I'd like to see this split up a bit so there's not so much in one
patch. Essentially, introduce cpu_setup_44x.S, move the FPU init to
use it, and then add the PLB workaround.
I still need to look at the code too :)
josh
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Josh Boyer @ 2007-09-20 18:02 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <200709201732.l8KHWuGA035995@sullivan.realtime.net>
On Thu, 20 Sep 2007 12:32:56 -0500 (CDT)
Milton Miller <miltonm@bga.com> wrote:
> On Fri Sep 21 02:56:32 EST 2007, Valentine Barshak wrote:
> > Josh Boyer wrote:
> >> On Wed, 19 Sep 2007 14:30:24 -0500
> >> Olof Johansson <olof at lixom.net> wrote:
> >>
> >>> On Wed, Sep 19, 2007 at 09:19:47PM +0200, Stefan Roese wrote:
> >>>> Hi Valentine,
> >>>>
> >>>> On Wednesday 19 September 2007, Valentine Barshak wrote:
> >>>>> Disabling write pipelining really helps.
> >>>>> Josh, David, what is the right place to put this workaround to?
> >>>>>
> >>>>> Is it OK to do mtdcr(PLB4A0_ACR, mfdcr(PLB4A0_ACR) & ~PLB4_WRP); in
> >>>>> arch/powerpc/boot/cuboot-sequoia.c:sequoia_fixups()?
> >>>>> or
> >>>>> should this be done in
> >>>>> arch/powerpc/platforms/44x/sequoia.c:sequoia_setup_arch()
> >>>>> with dcr_map, dcr_read/write stuff?
> >>>> I vote for putting it into sequoia.c, since it's very likely to happen that
> >>>> Sequoia will at one point be booted without the bootwrapper. Or perhaps it
> >>>> should go into some common code checking the PVR and disabling it when this
> >>>> 440EPx/GRx is detected, since all those boards are affected.
> >>> This is what we have setup_cpu functions in the cpu table for. Please
> >>> put it there instead of in board code.
> >>
> >> Yes, agreed.
> >
> > I was thinking about it. Looks like it's the best place, but the code
> > that actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> > cpu_setup functions are defined for ppc32 processors.
> > Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>
> head_32.S calls call_setup_cpu in misc_32.S to call the cpu setup functon.
>
> Note that these functions are called before the kernel is copied down to
> 0, so on ppc32 you will need the PTRRELOC type stuff. Also the callsite
> implies that the cpu number is available in r24, which may or may not be
> true when called from C.
>
> Its probably easier to just call call_setup_cpu in the other 32 bit
> head_xxx files.
Hm. I'll have to see how well that would work for 4xx. Seems 8xx and
FSL BookE are in a similar situation.
josh
^ permalink raw reply
* [PATCH] PowerPC: add setup_cpu for 44x for processor-specific init
From: Valentine Barshak @ 2007-09-20 17:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: miltonm, david
In-Reply-To: <200709201732.l8KHWuGA035995@sullivan.realtime.net>
This adds cpu_setup functionality to PowerPC 44x platform.
The cpu_setup callback is invoked by head_32 code and
the identify_cpu() function at early init and is used to
initialize FPU on 440EP(x) processors. The FPU initialization
was previously done in head_44x.S. Also a workaround for
the incorrect write to DDR SDRAM 440EPx/440GRx errata added.
Data can be written to wrong address in SDRAM when write
pipelining is enabled on plb0. The setup_cpu function
for these processors disables write pipelining.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/cpu_setup_44x.S | 54 ++++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/cputable.c | 25 ++++++++++------
arch/powerpc/kernel/head_44x.S | 10 ------
4 files changed, 70 insertions(+), 20 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/cpu_setup_44x.S linux-2.6/arch/powerpc/kernel/cpu_setup_44x.S
--- linux-2.6.orig/arch/powerpc/kernel/cpu_setup_44x.S 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/arch/powerpc/kernel/cpu_setup_44x.S 2007-09-20 21:05:44.000000000 +0400
@@ -0,0 +1,54 @@
+/*
+ * This file contains low level CPU setup functions.
+ * Valentine Barshak <vbarshak@ru.mvista.com>
+ * MontaVista Software, Inc (c) 2007
+ *
+ * Based on cpu_setup_6xx code by
+ * Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ *
+ * 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.
+ *
+ */
+
+#include <asm/processor.h>
+#include <asm/cputable.h>
+#include <asm/ppc_asm.h>
+
+_GLOBAL(__setup_cpu_440ep)
+ b __init_fpu_44x
+_GLOBAL(__setup_cpu_440epx)
+ mflr r4
+ bl __init_fpu_44x
+_GLOBAL(__setup_cpu_440grx)
+ bl __plb_disable_wrp
+ mtlr r4
+ blr
+
+/* enable APU between CPU and FPU */
+_GLOBAL(__init_fpu_44x)
+ mfspr r3,SPRN_CCR0
+ /* Clear DAPUIB flag in CCR0 */
+ rlwinm r3,r3,0,12,10
+ mtspr SPRN_CCR0,r3
+ isync
+ blr
+
+/*
+ * Workaround for the incorrect write to DDR SDRAM errata.
+ * The write address can be corrupted during writes to
+ * DDR SDRAM when write pipelining is enabled on PLB0.
+ * Disable write pipelining here.
+ */
+#define DCRN_PLB4A0_ACR 0x81
+
+_GLOBAL(__plb_disable_wrp)
+ mfdcr r3,DCRN_PLB4A0_ACR
+ /* clear WRP bit in PLB4A0_ACR */
+ rlwinm r3,r3,0,8,6
+ mtdcr DCRN_PLB4A0_ACR,r3
+ isync
+ blr
+
diff -ruN linux-2.6.orig/arch/powerpc/kernel/cputable.c linux-2.6/arch/powerpc/kernel/cputable.c
--- linux-2.6.orig/arch/powerpc/kernel/cputable.c 2007-09-20 19:30:47.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/cputable.c 2007-09-20 21:27:35.000000000 +0400
@@ -31,6 +31,9 @@
* and ppc64
*/
#ifdef CONFIG_PPC32
+extern void __setup_cpu_440ep(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_440epx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_440grx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -1111,6 +1114,7 @@
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440ep,
.platform = "ppc440",
},
{
@@ -1121,6 +1125,7 @@
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440ep,
.platform = "ppc440",
},
{ /* 440EPX */
@@ -1131,6 +1136,8 @@
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440epx,
+ .platform = "ppc440",
},
{ /* 440GRX */
.pvr_mask = 0xf0000ffb,
@@ -1140,6 +1147,8 @@
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440grx,
+ .platform = "ppc440",
},
{ /* 440GP Rev. B */
.pvr_mask = 0xf0000fff,
@@ -1318,18 +1327,14 @@
for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
if ((pvr & s->pvr_mask) == s->pvr_value) {
+ cpu_setup_t setup_func = PTRRELOC(s->cpu_setup);
+
*cur = cpu_specs + i;
-#ifdef CONFIG_PPC64
- /* ppc64 expects identify_cpu to also call setup_cpu
- * for that processor. I will consolidate that at a
- * later time, for now, just use our friend #ifdef.
- * we also don't need to PTRRELOC the function pointer
- * on ppc64 as we are running at 0 in real mode.
+ /* ppc expects identify_cpu to also call setup_cpu
+ * for that processor.
*/
- if (s->cpu_setup) {
- s->cpu_setup(offset, s);
- }
-#endif /* CONFIG_PPC64 */
+ if (setup_func)
+ setup_func(offset, s);
return s;
}
BUG();
diff -ruN linux-2.6.orig/arch/powerpc/kernel/head_44x.S linux-2.6/arch/powerpc/kernel/head_44x.S
--- linux-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-09-20 19:30:47.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/head_44x.S 2007-09-20 20:04:39.000000000 +0400
@@ -217,16 +217,6 @@
lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
mtspr SPRN_IVPR,r4
-#if defined(CONFIG_440EP) || defined(CONFIG_440EPX)
- /* Clear DAPUIB flag in CCR0 (enable APU between CPU and FPU) */
- mfspr r2,SPRN_CCR0
- lis r3,0xffef
- ori r3,r3,0xffff
- and r2,r2,r3
- mtspr SPRN_CCR0,r2
- isync
-#endif
-
/*
* This is where the main kernel code starts.
*/
diff -ruN linux-2.6.orig/arch/powerpc/kernel/Makefile linux-2.6/arch/powerpc/kernel/Makefile
--- linux-2.6.orig/arch/powerpc/kernel/Makefile 2007-09-20 19:30:47.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/Makefile 2007-09-20 19:52:21.000000000 +0400
@@ -56,6 +56,7 @@
udbg.o misc.o io.o
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += misc_64.o dma_64.o iommu.o
+obj-$(CONFIG_44x) += cpu_setup_44x.o
obj-$(CONFIG_PPC_MULTIPLATFORM) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_BOOTX_TEXT) += btext.o
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Olof Johansson @ 2007-09-20 18:03 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Josh Boyer, Stefan Roese, David Gibson
In-Reply-To: <20070920172506.GA16354@lixom.net>
On Thu, Sep 20, 2007 at 12:25:06PM -0500, Olof Johansson wrote:
> On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
> >
> > I was thinking about it. Looks like it's the best place, but the code that
> > actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> > cpu_setup functions are defined for ppc32 processors.
> > Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>
> Sounds like something that went wrong at the merge of ppc and ppc64.
>
> Take out the ifdef, even if there's fallout we should deal with it
> instead of adding more complex ifdefs.
See comment from Milton, my bad. It's just called from head_32.S right now.
It'll need to be added to the 4xx head as well, or an ifdef added. One or
the other, I'll leave it to Josh to pick.
-Olof
^ permalink raw reply
* Re: device tree question
From: Alan Bennett @ 2007-09-20 17:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46F19326.7050507@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 9947 bytes --]
Ok, making progress on the ep8248 / devtrees, etc...
But I'm not getting any output on the serial and my log_buf is pretty
clean. Without console; what's the best way to figure out why I'm not
getting any output on my SMC1 serial port (using u-boot , not planetcore)?
-Alan
__log_buf:
Using Embedded Planet EP8248E machine description.
Linux version 2.6.23-rc6-g943401ab-dirty (root@fremont) (gcc version 3.4.5)
#3 Wed Sep 19 12:51:18 MDT 2007.
Entering add_active_range(0, 0, 32768) 0 entries of 256 used.
Top of RAM: 0x8000000, Total RAM: 0x8000000.
Memory hole size: 0MB.
Zone PFN ranges:.
DMA 0 -> 32768.
Normal 32768 -> 32768.
Movable zone start PFN for each node.
early_node_map[1] active PFN ranges.
0: 0 -> 32768.
On node 0 totalpages: 32768.
DMA zone: 256 pages used for memmap.
DMA zone: 0 pages reserved.
DMA zone: 32512 pages, LIFO batch:7.
Normal zone: 0 pages used for memmap.
Movable zone: 0 pages used for memmap.
Built 1 zonelists in Zone order. Total pages: 32512.
Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth1
nfsroot=192.168.10.5:/fh/rfs rw .
PID hash table entries: 512 (order: 9, 2048 bytes).
time_init: decrementer frequency = 16.500000 MHz.
time_init: processor frequency = 231.000000 MHz..
dts file:
/*
* Device Tree for the Embedded Planet EP8248E board.
*
* Copyright 2007 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 = "EP8248E";
compatible = "fsl,ep8248e";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8248@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <d#32>;
i-cache-line-size = <d#32>;
d-cache-size = <d#16384>;
i-cache-size = <d#16384>;
timebase-frequency = <0>;
clock-frequency = <0>;
};
};
CS: chipselect {
compatible = "fsl,ep8248e-chipselect",
"fsl,mpc8248-chipselect",
"fsl,pq2-chipselect";
#address-cells = <2>;
#size-cells = <1>;
fsl,ctrl = <&CSCTRL>;
ranges = <0 0 f8000000 07f00000
0 1 fff00000 00080000
0 2 fff80000 00080000
1 0 e4000000 00008000
2 0 d0000000 08000000>;
/* F800_0000 -> FFF0_0000 */
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0 7F00000>;
probe-type = "CFI";
bank-width = <4>;
};
/* FFF0_0000 -> FFF7_FFFF */
flash@0,1 {
device_type = "rom";
compatible = "direct-mapped";
reg = <0 0 80000>;
probe-type = "CFI";
bank-width = <4>;
};
/* FFF8_0000 -> FFFF_FFFF */
flash@0,2 {
compatible = "cfi-flash";
reg = <0 0 80000>;
probe-type = "CFI";
bank-width = <4>;
};
/* F400_0000 */
bcsr@1,0 {
#address-cells = <2>;
#size-cells = <1>;
reg = <1 0 10>;
compatible = "fsl,ep8248e-bcsr";
ranges;
mdio {
device_type = "mdio";
compatible = "fsl,ep8248e-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <1 8 1>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
reg = <1>;
device_type = "ethernet-phy";
};
};
};
/* D000_0000 -> D7FF_FFFF */
flash@2,0 {
compatible = "cfi-flash";
reg = <0 0 08000000>;
probe-type = "CFI";
bank-width = <4>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8248", "fsl,pq2-soc";
ranges = <00000000 f0000000 00053000>;
CSCTRL: chipselect {
compatible = "fsl,mpc8248-chipselect-ctrl",
"fsl,pq2-chipselect-ctrl";
reg = <10100 40>;
fsl,bus = <&CS>;
};
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8248-cpm", "fsl,cpm2";
reg = <119c0 30 0 1100>;
ranges;
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 1100 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d000000>;
linux,planetcore-label = "SMC1";
};
/* "Serial" port/SCC1 */
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
linux,planetcore-label = "SCC1";
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
usb@11b60 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8248-usb",
"fsl,cpm2-usb";
reg = <11b60 18 8b00 100>;
interrupt-parent = <&PIC>;
interrupts = <b 8>;
fsl,cpm-command = <2e600000>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8248-pic", "fsl,pq2-pic";
};
};
};
[-- Attachment #2: Type: text/html, Size: 33565 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] Implement generic time of day clocksource for powerpc machines.
From: john stultz @ 2007-09-20 16:35 UTC (permalink / raw)
To: Paul Mackerras
Cc: Realtime Kernel, Daniel Walker, Thomas Gleixner, linuxppc-dev
In-Reply-To: <18161.50240.599267.768383@cargo.ozlabs.ibm.com>
On Thu, 2007-09-20 at 10:52 +1000, Paul Mackerras wrote:
> Daniel Walker writes:
>
> > If you switch to the rtc do the shift and mult need to change?
>
> You can't switch; any given CPU chip will have either the RTC or the
> timebase but not both.
I think what Daniel is pointing out is that the clocksource read
function isn't the place for the __USE_RTC() conditional.
It would likely be better instead of the timebase clocksource managing
multiple type of hardware (timebase and RTC), to have a separate simple
RTC clocksource, and then conditionally register one or the other at
init time.
thanks
-john
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix QEIC->MPIC cascading
From: Anton Vorontsov @ 2007-09-20 17:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46F2A7CC.1040106@freescale.com>
On Thu, Sep 20, 2007 at 12:03:08PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>> set_irq_chained_handler overwrites MPIC's handle_irq function
>> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
>> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>
> I'm not familiar with the differences between IPIC and MPIC. What is this
> patch not needed for 83xx?
Yup, this patch not needed for 83xx. IPIC doesn't have end()/eoi().
(..and MPIC doesn't have ack()).
Though...
Idially QEIC should do both ack() and end(), at the beginning and at
the end of irq handling respectively.
I don't know (didn't look) why this works for 83xx w/o ack()...
maybe IPIC don't need this. Or maybe there is a bug hiding.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Milton Miller @ 2007-09-20 17:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46F2A640.1000802@ru.mvista.com>
On Fri Sep 21 02:56:32 EST 2007, Valentine Barshak wrote:
> Josh Boyer wrote:
>> On Wed, 19 Sep 2007 14:30:24 -0500
>> Olof Johansson <olof at lixom.net> wrote:
>>
>>> On Wed, Sep 19, 2007 at 09:19:47PM +0200, Stefan Roese wrote:
>>>> Hi Valentine,
>>>>
>>>> On Wednesday 19 September 2007, Valentine Barshak wrote:
>>>>> Disabling write pipelining really helps.
>>>>> Josh, David, what is the right place to put this workaround to?
>>>>>
>>>>> Is it OK to do mtdcr(PLB4A0_ACR, mfdcr(PLB4A0_ACR) & ~PLB4_WRP); in
>>>>> arch/powerpc/boot/cuboot-sequoia.c:sequoia_fixups()?
>>>>> or
>>>>> should this be done in
>>>>> arch/powerpc/platforms/44x/sequoia.c:sequoia_setup_arch()
>>>>> with dcr_map, dcr_read/write stuff?
>>>> I vote for putting it into sequoia.c, since it's very likely to happen that
>>>> Sequoia will at one point be booted without the bootwrapper. Or perhaps it
>>>> should go into some common code checking the PVR and disabling it when this
>>>> 440EPx/GRx is detected, since all those boards are affected.
>>> This is what we have setup_cpu functions in the cpu table for. Please
>>> put it there instead of in board code.
>>
>> Yes, agreed.
>
> I was thinking about it. Looks like it's the best place, but the code
> that actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> cpu_setup functions are defined for ppc32 processors.
> Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
head_32.S calls call_setup_cpu in misc_32.S to call the cpu setup functon.
Note that these functions are called before the kernel is copied down to
0, so on ppc32 you will need the PTRRELOC type stuff. Also the callsite
implies that the cpu number is available in r24, which may or may not be
true when called from C.
Its probably easier to just call call_setup_cpu in the other 32 bit
head_xxx files.
milton
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Josh Boyer @ 2007-09-20 17:29 UTC (permalink / raw)
To: Olof Johansson, benh; +Cc: linuxppc-dev, Josh Boyer, Stefan Roese, David Gibson
In-Reply-To: <20070920172506.GA16354@lixom.net>
On Thu, 20 Sep 2007 12:25:06 -0500
Olof Johansson <olof@lixom.net> wrote:
> On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
> >
> > I was thinking about it. Looks like it's the best place, but the code that
> > actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> > cpu_setup functions are defined for ppc32 processors.
> > Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>
> Sounds like something that went wrong at the merge of ppc and ppc64.
>
> Take out the ifdef, even if there's fallout we should deal with it
> instead of adding more complex ifdefs.
Yeah. Looks like BenH did this in commit:
42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc
Ben, any reason you ifdef'd it for ppc64?
josh
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Olof Johansson @ 2007-09-20 17:25 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Josh Boyer, Stefan Roese, David Gibson
In-Reply-To: <46F2A640.1000802@ru.mvista.com>
On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
>
> I was thinking about it. Looks like it's the best place, but the code that
> actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
> cpu_setup functions are defined for ppc32 processors.
> Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
Sounds like something that went wrong at the merge of ppc and ppc64.
Take out the ifdef, even if there's fallout we should deal with it
instead of adding more complex ifdefs.
-Olof
^ permalink raw reply
* Re: The ds1337 chip on fsl_mp8313E RDB REVA 3 doesn't work properly
From: Kim Phillips @ 2007-09-20 17:19 UTC (permalink / raw)
To: Andrew Liu; +Cc: linuxppc-embedded
In-Reply-To: <46F238BB.4040007@windriver.com>
On Thu, 20 Sep 2007 17:09:15 +0800
Andrew Liu <shengping.liu@windriver.com> wrote:
> Hello All,
> The same u-boot/kernel/rootfs on fsl_mp8313E RDB REVA 2, DS1337 RTC
> chip can work,
> but on sl_mp8313E RDB REVA 3, it doesn't work, its time don't change.
>
> This RTC chip specific bad behavior on sl_mp8313E RDB REVA 3 as follows:
> (1) On U-Boot (from Freescale), run command:
> => i2c md 0x68 0x0
> 0000: 32 33 10 04 20 89 08 84 00 20 53 00 42 16 18 80 23.. .... S.B...
looks like your oscillator is turned off (80 in status reg).
There are many reasons this can happen - google for 'dallas 1337 rtc'
for the chip's documentation to help you diagnose.
Kim
^ permalink raw reply
* [patch 5/7] Use extended crashkernel command line on ppc64
From: Bernhard Walle @ 2007-09-20 17:18 UTC (permalink / raw)
To: kexec, akpm; +Cc: linux-arch, linuxppc-dev, linux-kernel
In-Reply-To: <20070920171845.774383000@stravinsky.suse.de>
This patch adapts the ppc64 code to use the generic parse_crashkernel()
function introduced in the generic patch of that series.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
arch/powerpc/kernel/machine_kexec.c | 52 ++++++++++++++++++------------------
1 file changed, 26 insertions(+), 26 deletions(-)
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -61,45 +61,39 @@ NORET_TYPE void machine_kexec(struct kim
for(;;);
}
-static int __init early_parse_crashk(char *p)
+void __init reserve_crashkernel(void)
{
- unsigned long size;
-
- if (!p)
- return 1;
-
- size = memparse(p, &p);
+ unsigned long long crash_size = 0, crash_base;
+ int ret;
- if (*p == '@')
- crashk_res.start = memparse(p + 1, &p);
- else
- crashk_res.start = KDUMP_KERNELBASE;
-
- crashk_res.end = crashk_res.start + size - 1;
-
- return 0;
-}
-early_param("crashkernel", early_parse_crashk);
+ /* this is necessary because of lmb_phys_mem_size() */
+ lmb_analyze();
-void __init reserve_crashkernel(void)
-{
- unsigned long size;
+ /* use common parsing */
+ ret = parse_crashkernel(boot_command_line, lmb_phys_mem_size(),
+ &crash_size, &crash_base);
+ if (ret == 0 && crash_size > 0) {
+ if (crash_base == 0)
+ crash_base = KDUMP_KERNELBASE;
+ crashk_res.start = crash_base;
+ } else {
+ /* handle the device tree */
+ crash_size = crashk_res.end - crashk_res.start + 1;
+ }
- if (crashk_res.start == 0)
+ if (crash_size == 0)
return;
/* We might have got these values via the command line or the
* device tree, either way sanitise them now. */
- size = crashk_res.end - crashk_res.start + 1;
-
if (crashk_res.start != KDUMP_KERNELBASE)
printk("Crash kernel location must be 0x%x\n",
KDUMP_KERNELBASE);
crashk_res.start = KDUMP_KERNELBASE;
- size = PAGE_ALIGN(size);
- crashk_res.end = crashk_res.start + size - 1;
+ crash_size = PAGE_ALIGN(crash_size);
+ crashk_res.end = crashk_res.start + crash_size - 1;
/* Crash kernel trumps memory limit */
if (memory_limit && memory_limit <= crashk_res.end) {
@@ -108,7 +102,13 @@ void __init reserve_crashkernel(void)
memory_limit);
}
- lmb_reserve(crashk_res.start, size);
+ printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
+ "for crashkernel (System RAM: %ldMB)\n",
+ (unsigned long)(crash_size >> 20),
+ (unsigned long)(crashk_res.start >> 20),
+ (unsigned long)(lmb_phys_mem_size() >> 20));
+
+ lmb_reserve(crashk_res.start, crash_size);
}
int overlaps_crashkernel(unsigned long start, unsigned long size)
--
^ permalink raw reply
* Re: Cleanups for physmap_of.c (v2)
From: Segher Boessenkool @ 2007-09-20 17:11 UTC (permalink / raw)
To: David Gibson; +Cc: Vitaly Wool, David Woodhouse, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070920012225.GG14404@localhost.localdomain>
> - (the big one) Despite the name, this driver really has
> nothing to do with drivers/mtd/physmap.c. The fact that the flash
> chips must be physically direct mapped is a constrant, but doesn't
> really say anything about the actual purpose of this driver, which is
> to instantiate MTD devices based on information from the device tree.
> Therefore the physmap name is replaced everywhere within the file with
> "of_flash".
Do you think this code will handle NAND flash later, too? If not,
maybe "of_norflash" is better?
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix QEIC->MPIC cascading
From: Timur Tabi @ 2007-09-20 17:03 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070920130244.GA18043@localhost.localdomain>
Anton Vorontsov wrote:
> set_irq_chained_handler overwrites MPIC's handle_irq function
> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
> cascaded IRQ. This situation hangs MPIC on MPC8568E.
I'm not familiar with the differences between IPIC and MPIC. What is this
patch not needed for 83xx?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Valentine Barshak @ 2007-09-20 16:56 UTC (permalink / raw)
To: Josh Boyer
Cc: Olof Johansson, linuxppc-dev, Josh Boyer, Stefan Roese,
David Gibson
In-Reply-To: <20070919150818.3fecc1bc@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 19 Sep 2007 14:30:24 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
>> On Wed, Sep 19, 2007 at 09:19:47PM +0200, Stefan Roese wrote:
>>> Hi Valentine,
>>>
>>> On Wednesday 19 September 2007, Valentine Barshak wrote:
>>>> Disabling write pipelining really helps.
>>>> Josh, David, what is the right place to put this workaround to?
>>>>
>>>> Is it OK to do mtdcr(PLB4A0_ACR, mfdcr(PLB4A0_ACR) & ~PLB4_WRP); in
>>>> arch/powerpc/boot/cuboot-sequoia.c:sequoia_fixups()?
>>>> or
>>>> should this be done in
>>>> arch/powerpc/platforms/44x/sequoia.c:sequoia_setup_arch()
>>>> with dcr_map, dcr_read/write stuff?
>>> I vote for putting it into sequoia.c, since it's very likely to happen that
>>> Sequoia will at one point be booted without the bootwrapper. Or perhaps it
>>> should go into some common code checking the PVR and disabling it when this
>>> 440EPx/GRx is detected, since all those boards are affected.
>> This is what we have setup_cpu functions in the cpu table for. Please
>> put it there instead of in board code.
>
> Yes, agreed.
I was thinking about it. Looks like it's the best place, but the code
that actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
cpu_setup functions are defined for ppc32 processors.
Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
Thanks,
Valentine.
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 3/3] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Roland Dreier @ 2007-09-20 16:29 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200709131816.21162.fenkes@de.ibm.com>
thanks, applied this and the umem patch...
^ permalink raw reply
* Re: Printing device tree on running system
From: Jon Smirl @ 2007-09-20 16:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070920160804.GA15796@ld0162-tx32.am.freescale.net>
On 9/20/07, Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Sep 20, 2007 at 11:55:10AM -0400, Jon Smirl wrote:
> > Is there a command for printing the device tree on a running system? I
> > want to see what changes the various device drivers made to the DTC I
> > started with.
>
> It's exported in /proc/device-tree, if support is built into the kernel.
That worked, didn't know the option existed.
>
> It might be interesting to make dtc support turning that into a dts...
That would be useful, you could do a diff and see how the tree was altered.
The case I just looked at was old code manually building entries for
i2c devices in the tree, but with an updated dts the devices are
already in the tree which explains the error I got about conflicting
device nodes.
>
> -Scott
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Printing device tree on running system
From: Scott Wood @ 2007-09-20 16:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709200855p5a1cdf18v1848a31c7935ca5e@mail.gmail.com>
On Thu, Sep 20, 2007 at 11:55:10AM -0400, Jon Smirl wrote:
> Is there a command for printing the device tree on a running system? I
> want to see what changes the various device drivers made to the DTC I
> started with.
It's exported in /proc/device-tree, if support is built into the kernel.
It might be interesting to make dtc support turning that into a dts...
-Scott
^ 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