* [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
Author: Olof Johansson <olof@lixom.net>
Date: Tue Sep 4 21:53:30 2007 -0500
[POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
Move pasemi_idle_init() to be a late_initcall instead of being called from
setup_arch(). This way the cpufreq driver has a chance to initialize and
save away the boot time astate before we go to idle for the first time.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 3c962d5..d8e1fcc 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -72,8 +72,11 @@ static int pasemi_system_reset_exception(struct pt_regs *regs)
return 1;
}
-void __init pasemi_idle_init(void)
+static int __init pasemi_idle_init(void)
{
+ if (!machine_is(pasemi))
+ return -ENODEV;
+
#ifndef CONFIG_PPC_PASEMI_CPUFREQ
printk(KERN_WARNING "No cpufreq driver, powersavings modes disabled\n");
current_mode = 0;
@@ -82,7 +85,10 @@ void __init pasemi_idle_init(void)
ppc_md.system_reset_exception = pasemi_system_reset_exception;
ppc_md.power_save = modes[current_mode].entry;
printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
+
+ return 0;
}
+late_initcall(pasemi_idle_init);
static int __init idle_param(char *p)
{
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index 6fd2fe7..516acab 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -10,8 +10,6 @@ extern void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset);
extern void __init alloc_iobmap_l2(void);
-extern void __init pasemi_idle_init(void);
-
/* Power savings modes, implemented in asm */
extern void idle_spin(void);
extern void idle_doze(void);
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index fe9a5d6..5ddf40a 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -115,8 +115,6 @@ void __init pas_setup_arch(void)
/* Remap SDC register for doing reset */
/* XXXOJN This should maybe come out of the device tree */
reset_reg = ioremap(0xfc101100, 4);
-
- pasemi_idle_init();
}
static int __init pas_setup_mce_regs(void)
^ permalink raw reply related
* Re: [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-05 0:39 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905023612.GD17189@localhost.localdomain>
On Wed, 2007-09-05 at 12:36 +1000, David Gibson wrote:
> On Tue, Sep 04, 2007 at 07:42:03AM -0500, Josh Boyer wrote:
> > On Sun, 02 Sep 2007 08:59:44 -0500
> > Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> [snip]
> > > > > + POB0: opb {
> > > > > + compatible = "ibm,opb";
> > > >
> > > > Need an opb-405gp here, too.
> > >
> > > Yep.
> >
> > Fixed.
> >
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges = <0 ef600000 a00000>;
> > > >
> > > > Hrm... something we ought to clarify is the interpretation of the
> > > > POB0_BEAR register with respect to the bridge's ranges property. For
> > > > 440 I think the BEAR will need to be interpreted as an OPB address,
> > > > rather than a PLB address, but I'm not sure if that will work here
> > > > with the limited ranges property you have.
> > >
> > > Ok, I'll look at this.
> >
> > The BEAR will still be interpreted as a PLB address here as far as I
> > can see. The ranges spans the entire OPB space. Am I missing
> > something?
>
> Ah, sorry, my mistake. I thought the BEAR register would encode an
> OPB address rather than a PLB address (and thus, be only 32-bits wide
> on 440). In fact it appears it does encode a PLB address (and is
> split into BEARH and BEARL registers on 440).
Right.
> Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
> POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
> space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
> describing just the address range used by OPB peripherals
> (0xef600000-0xf0000000) as residing at address 0 in OPB-space.
>
> Since the ranges will still generate the right physical addresses, I
> guess it doesn't matter. But I'm not sure it meets the principle of
> least surprise - since I think the documentation generally talks as
> though addresses on the 405 OPB bus are identical to addreses on the
> PLB.
I don't care either way. If I remember correctly, this way of doing it
came out of a discussion with Segher.
josh
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-05 0:40 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905011045.GC17189@localhost.localdomain>
On Wed, 2007-09-05 at 11:10 +1000, David Gibson wrote:
> On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> > On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > > linker declarations that have been moved into ops.h
> > > >
> > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > [snip]
> > > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > > @@ -24,8 +24,7 @@
> > > > #include "4xx.h"
> > > > #include "44x.h"
> > > >
> > > > -extern char _dtb_start[];
> > > > -extern char _dtb_end[];
> > > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > > >
> > > > static void bamboo_fixups(void)
> > > > {
> > > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > > ibm4xx_fixup_memsize();
> > > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > > + if (bamboo_mac0 && bamboo_mac1)
> > > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> > >
> > > Bit ugly that you only set the MAC address for any ethernet if they're
> > > supplied for every ethernet.
> >
> > Good point. Will fix.
> >
> > > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > > - bamboo_init();
> > > > + bamboo_init(NULL, NULL);
> > >
> > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> >
> > Probably. I just need to find out where they are stored.
>
> It's not buried somewhere in the arch/ppc/boot code?
It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
I'd rather avoid. But I did find where it's stored in flash, so I can
read it from there. I just need to do a little more work to get it in a
manner that can be used.
josh
^ permalink raw reply
* [PATCH] powerpc: Remove unused platform_machine_check()
From: Olof Johansson @ 2007-09-05 2:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Remove leftover cruft from ARCH=ppc.
There are no users of platform_machine_check() in ARCH=powerpc, and none
should be added (they should use ppc_md.machine_check_handler instead).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index d8502e3..ccfc99d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -324,15 +324,6 @@ static inline int check_io_access(struct pt_regs *regs)
#define clear_single_step(regs) ((regs)->msr &= ~MSR_SE)
#endif
-/*
- * This is "fall-back" implementation for configurations
- * which don't provide platform-specific machine check info
- */
-void __attribute__ ((weak))
-platform_machine_check(struct pt_regs *regs)
-{
-}
-
void machine_check_exception(struct pt_regs *regs)
{
int recover = 0;
@@ -480,12 +471,6 @@ void machine_check_exception(struct pt_regs *regs)
}
#endif /* CONFIG_4xx */
- /*
- * Optional platform-provided routine to print out
- * additional info, e.g. bus error registers.
- */
- platform_machine_check(regs);
-
if (debugger_fault_handler(regs))
return;
die("Machine check", regs, SIGBUS);
^ permalink raw reply related
* [PATCH] powerpc: Don't use generic machine check parsing everywhere
From: Olof Johansson @ 2007-09-05 2:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
If a platform provide it's own machine check handler, assume that code
will handle the reason parsing and reporting the error. The current
default fall-though only makes sense on a few 32-bit platforms that
lack individual handlers.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index ccfc99d..ce1aafc 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -440,34 +440,36 @@ void machine_check_exception(struct pt_regs *regs)
if (reason & MCSR_BUS_WRERR)
printk("Bus - Write Bus Error on buffered store or cache line push\n");
#else /* !CONFIG_4xx && !CONFIG_E500 && !CONFIG_E200 */
- printk("Machine check in kernel mode.\n");
- printk("Caused by (from SRR1=%lx): ", reason);
- switch (reason & 0x601F0000) {
- case 0x80000:
- printk("Machine check signal\n");
- break;
- case 0: /* for 601 */
- case 0x40000:
- case 0x140000: /* 7450 MSS error and TEA */
- printk("Transfer error ack signal\n");
- break;
- case 0x20000:
- printk("Data parity error signal\n");
- break;
- case 0x10000:
- printk("Address parity error signal\n");
- break;
- case 0x20000000:
- printk("L1 Data Cache error\n");
- break;
- case 0x40000000:
- printk("L1 Instruction Cache error\n");
- break;
- case 0x00100000:
- printk("L2 data cache parity error\n");
- break;
- default:
- printk("Unknown values in msr\n");
+ if (!ppc_md.machine_check_exception) {
+ printk("Machine check in kernel mode.\n");
+ printk("Caused by (from SRR1=%lx): ", reason);
+ switch (reason & 0x601F0000) {
+ case 0x80000:
+ printk("Machine check signal\n");
+ break;
+ case 0: /* for 601 */
+ case 0x40000:
+ case 0x140000: /* 7450 MSS error and TEA */
+ printk("Transfer error ack signal\n");
+ break;
+ case 0x20000:
+ printk("Data parity error signal\n");
+ break;
+ case 0x10000:
+ printk("Address parity error signal\n");
+ break;
+ case 0x20000000:
+ printk("L1 Data Cache error\n");
+ break;
+ case 0x40000000:
+ printk("L1 Instruction Cache error\n");
+ break;
+ case 0x00100000:
+ printk("L2 data cache parity error\n");
+ break;
+ default:
+ printk("Unknown values in msr\n");
+ }
}
#endif /* CONFIG_4xx */
^ permalink raw reply related
* [PATCH] powerpc: Move lowlevel runlatch calls under cpu feature control
From: Olof Johansson @ 2007-09-05 2:42 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
There's no need to call the runlatch on functions on processors that
don't implement them (CPU_FTR_CTRL).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 33c4e8c..cec5908 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -656,7 +656,9 @@ hardware_interrupt_common:
FINISH_NAP
hardware_interrupt_entry:
DISABLE_INTS
+BEGIN_FTR_SECTION
bl .ppc64_runlatch_on
+END_FTR_SECTION_IFSET(CPU_FTR_CTRL)
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_IRQ
b .ret_from_except_lite
diff --git a/include/asm-powerpc/exception.h b/include/asm-powerpc/exception.h
index d850c8e..39abdb0 100644
--- a/include/asm-powerpc/exception.h
+++ b/include/asm-powerpc/exception.h
@@ -282,7 +282,9 @@ label##_common: \
EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \
FINISH_NAP; \
DISABLE_INTS; \
+BEGIN_FTR_SECTION \
bl .ppc64_runlatch_on; \
+END_FTR_SECTION_IFSET(CPU_FTR_CTRL) \
addi r3,r1,STACK_FRAME_OVERHEAD; \
bl hdlr; \
b .ret_from_except_lite
^ permalink raw reply related
* [PATCH] powerpc: Remove warning in arch/powerpc/kernel/sysfs.c
From: Olof Johansson @ 2007-09-05 2:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
arch/powerpc/kernel/sysfs.c: In function 'cpu_add_sysdev_attr_group':
arch/powerpc/kernel/sysfs.c:388: warning: ignoring return value of
'sysfs_create_group', declared with attribute warn_unused_result
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 55d29ed..63c0302 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -380,12 +380,14 @@ int cpu_add_sysdev_attr_group(struct attribute_group *attrs)
{
int cpu;
struct sys_device *sysdev;
+ int ret;
mutex_lock(&cpu_mutex);
for_each_possible_cpu(cpu) {
sysdev = get_cpu_sysdev(cpu);
- sysfs_create_group(&sysdev->kobj, attrs);
+ ret = sysfs_create_group(&sysdev->kobj, attrs);
+ WARN_ON(ret != 0);
}
mutex_unlock(&cpu_mutex);
^ permalink raw reply related
* [PATCH] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-05 2:44 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.
To work around this, keep a software copy of the register instead. Since
it's not modified from the mpic itself, it's a feasible solution. Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 041df77..b9f1efa 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -137,6 +137,10 @@ config MPIC_U3_HT_IRQS
depends on PPC_MAPLE
default y
+config MPIC_BROKEN_REGREAD
+ bool
+ depends on PPC_PASEMI
+
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 95cd90f..117d90a 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 74c64c0..c0fe063 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -228,8 +228,13 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigne
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ return mpic->isu_reg0_shadow[idx];
+ else
+#endif
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -240,6 +245,11 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
_mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
+
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ mpic->isu_reg0_shadow[idx] = value;
+#endif
}
#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 262db6b..c877fa7 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -309,6 +309,10 @@ struct mpic
unsigned long *hwirq_bitmap;
#endif
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ u32 isu_reg0_shadow[MPIC_MAX_IRQ_SOURCES];
+#endif
+
/* link */
struct mpic *next;
^ permalink raw reply related
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-05 5:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188952819.3223.5.camel@localhost.localdomain>
On Tue, Sep 04, 2007 at 07:40:19PM -0500, Josh Boyer wrote:
> On Wed, 2007-09-05 at 11:10 +1000, David Gibson wrote:
> > On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> > > On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > > > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > > > linker declarations that have been moved into ops.h
> > > > >
> > > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > > >
> > > > [snip]
> > > > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > > > @@ -24,8 +24,7 @@
> > > > > #include "4xx.h"
> > > > > #include "44x.h"
> > > > >
> > > > > -extern char _dtb_start[];
> > > > > -extern char _dtb_end[];
> > > > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > > > >
> > > > > static void bamboo_fixups(void)
> > > > > {
> > > > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > > > ibm4xx_fixup_memsize();
> > > > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > > > + if (bamboo_mac0 && bamboo_mac1)
> > > > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> > > >
> > > > Bit ugly that you only set the MAC address for any ethernet if they're
> > > > supplied for every ethernet.
> > >
> > > Good point. Will fix.
> > >
> > > > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > > > - bamboo_init();
> > > > > + bamboo_init(NULL, NULL);
> > > >
> > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > >
> > > Probably. I just need to find out where they are stored.
> >
> > It's not buried somewhere in the arch/ppc/boot code?
>
> It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> I'd rather avoid. But I did find where it's stored in flash, so I can
> read it from there. I just need to do a little more work to get it in a
> manner that can be used.
Hrm.. is that address actually guaranteed to be stable across PIBS
versions? If arch/ppc uses __res, I think we should do that too. It
shouldn't be any worse than what we already do fot cuboot.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/9] 8xx: Add pin and clock setting functions.
From: Vitaly Bordug @ 2007-09-05 7:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070831204418.GA3461@ld0162-tx32.am.freescale.net>
On Fri, 31 Aug 2007 15:44:18 -0500
Scott Wood wrote:
> > > + u32 mask = 7;
> > > +
> > gotta at least briefly explain the clue here, too.
>
> I'm not sure what you mean... what exactly are you asking me to
> explain?
>
> Note that this code is mostly duplicated from the existing CPM2
> version.
>
Then it would be good to mention that in short comment block before function.
> > We're adding helper functions and should be ready that something
> > somewhere won't work as expected.
>
> Could you elaborate on what you expect to possibly not work, or what
> we should do to "be ready"?
Some new PQ-like board being added to powerpc. I mean, each newly-added non-static function should have some sort of
description unless it(function) is completely self-explanatory.
Just a few words either here as a comment or in patch description, what the function supposed to do
and which way, so that someone not familiar with cpm/cpm2, would quickly understand
what's happening in there.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-05 8:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40709040747j503a2054x27ba2b8146a93ff8@mail.gmail.com>
Grant Likely wrote:
> On 9/4/07, Thomas Gerlach <gerlach@kip.uni-heidelberg.de> wrote:
>
>> hi folks,
>>
>>
>> my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
>>
>> as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
>>
>> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>>
>
> You should be using a Linux cross compiler, not powerpc-eabi-. The
> Xilinx cross compiler will not work to compile Linux kernels.
>
> You can build yourself a cross compiler using 'crosstool':
> http://www.kegel.org/crosstool.
>
> Alternately, you can download ELDK:
> http://www.denx.de/wiki/view/DULG/ELDKAvailability
>
> Cheers,
> g.
>
>
hi,
thank you much for this hint. this was the last thing i thought of... ;)
so long, keep on cross-compiling! :)
regards,
thomas
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-05 8:18 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070904213339.D3DB7788046@mail56-fra.bigfish.com>
Wolfgang Reissnegger wrote:
> Hi Thomas,
>
> Xilinx is building the tools in the EDK to work with VxWorks and for Standalone systems. In order to compile a Linux kernel you need to get a toolchain from one of the Third Party vendors, such as MontaVista. They have the correct linker scripts for building a kernel.
>
> Cheers,
> Wolfgang
>
> Thomas Gerlach wrote:
>
>> hi folks,
>>
>>
>> my name is thomas trying to make embedded linux run on a powerpc, but
>> we've got special boards here, although we use a xilinx virtex4
>> fpga...
>>
>> as you said in the nabble-thread (see subject), i set up edk9.1
>> software platform settings und ran libgen to get the xparameters*
>> files. i copied those bsp files into the kernel tree (i use your
>> kernel linux-2.6-virtex from git.secretlabs.ca/git). after
>> configuring the kernel settigs, i try
>>
>> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>>
>> what i get is the following output:
>>
>>
>>> CHK include/linux/version.h
>>> CHK include/linux/utsrelease.h
>>> CALL scripts/checksyscalls.sh
>>> CHK include/linux/compile.h
>>> LD init/mounts.o
>>> powerpc-eabi-ld: cannot find boot.o
>>> make[1]: *** [init/mounts.o] Error 1
>>> make: *** [init] Error 2
>>>
>> so, i searched for boot.o (it exists) and even copied it into several
>> dirs of the linux kernel tree (where i thought i would make sense),
>> but the problem still remains.
>>
>> googling results in
>>
>> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
>>
>>
>> and this, too, doesn't take me further in solving the problem.
>>
>> i hope you can help me.
>>
>> many thanks in advance,
>>
>> kind regards
>> thomas gerlach
>>
hi,
thank you much for this hint, i'll try it. this was the last thing i
thought of... ;)
kepp on cross-compiling, :)
regards
thomas
^ permalink raw reply
* Problems enabling NTP on ELDK
From: Johan Borkhuis @ 2007-09-05 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I tried enabling NTP on my embedded machine (using ELDK 4.1, ppc_85xx,
kernel version 2.6.14 with Xenomai 2.3.2). After I did that I noticed
that ksoftirqd/0 suddenly took almost all processor time (> 95%). What
is causing this? Is there a way around this, or is this something that
does not cause any problems?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-09-05 11:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904182028.GC18280@ld0162-tx32.am.freescale.net>
On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote:
> > > _and system GPIOs_ :-)
> >
> > Yup, firmware should set up gpios, to make initial kernel boot.
>
> No, it should set all pins and similar setup-once type initialization
> that is board-specific rather than device-specific -- there's no reason
> for the kernel to need to care about that sort of thing.
>
> > After that, kernel can and should manage GPIOs. Few examples.
> >
> > Say units (like USB or SPI) can work in very different modes. And
> > it's okay if user want to change device mode in the runtime.
>
> This is a special case that warrants kernel involvement. It should not
> be used as justification for the bootloader leaving pins unconfigured in
> the majority of cases where it does not make sense to change them at
> runtime.
>
> > Another example, power management - if some unit temporarily unused,
> > to save power GPIOs should be set up differently. Say if SPI unit
> > turned off (unused just now), it's wise to bring their dedicated
> > GPIOs to "power saving" state (be it output0/1 or input, it
> > depends).
>
> The kernel is of course welcome to do so -- and this may be a valid
> reason to attach pin information to specific device nodes, if it actually
> saves a non-negligible amount of power -- but it's not a reason to force
> the kernel to have to care by not setting things up in the firmware.
Well, I might agree here. But to me it seems unnatural that I have to
upgrade bootloader to use SPI -- I can already boot the kernel.
Bootloader's duties are finished when kernel booted. And if already
running kernel is unable to do something, it's not bootloader's fault
anymore, but kernel's itself. At least I like to think so. Maybe I'm
wrong, yet not sure. ;-)
And from the practical point of view, upgrading bootloader is much
more error-prone and risky for the users without proper rescue tools
and knowledge. Kernel is easier to deploy after bug-fixing (and
wrongly set up GPIO pin is a bug). That's why I tend to like "dumb
and simple" bootloaders and do not hang up too much duties on it.
Anyhow, all above is just my own preference, I'm not arguing at
all, because personally I'm fine with any option, be it dts, board
file, device driver's file, the bootloader, or all at once. ;-)
> -Scott
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: Segher Boessenkool @ 2007-09-05 11:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1188952766.3223.3.camel@localhost.localdomain>
>> Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
>> POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
>> space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
>> describing just the address range used by OPB peripherals
>> (0xef600000-0xf0000000) as residing at address 0 in OPB-space.
>>
>> Since the ranges will still generate the right physical addresses, I
>> guess it doesn't matter. But I'm not sure it meets the principle of
>> least surprise - since I think the documentation generally talks as
>> though addresses on the 405 OPB bus are identical to addreses on the
>> PLB.
>
> I don't care either way. If I remember correctly, this way of doing it
> came out of a discussion with Segher.
I don't think I ever said that this is a better way of doing things --
then again, I change my mind now and then.
Someone needs to write down a proposed device binding for these busses,
and then we can really discuss things ;-)
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Gerhard Pircher @ 2007-09-05 11:54 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905024805.GE17189@localhost.localdomain>
-------- Original-Nachricht --------
> Datum: Wed, 5 Sep 2007 12:48:05 +1000
> Von: David Gibson <david@gibson.dropbear.id.au>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Segher Boessenkool <segher@kernel.crashing.org>, linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2
> That looks totally bogus. Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example). But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.
AmigaOne's PCI bridge implements PCI config with indirect addressing, but
not within the ISA I/O space. I just wanted to clear up the meaning of
this reg entry, because it looks like everyone interprets the OF spec a
little bit differently.
> > > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > > PowerPC system bus. So, it can not be mentioned in the "ranges"
> > > property, but the PHB registers used to access it should be shown
> > > in the "reg" property. It could be a simple linear window (it
> > > sounds like it is here?), but it could for example also be
> > > implemented via an address/data register pair.
>
> Err... huh? The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding. When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.
I defined the legacy I/O space together with the PCI I/O space in the
ranges property of the PCI node:
ranges = <01000000 0 00000000 fe000000 0 00c00000
The first 64k of this address space are mapped to ISA I/O in the PCI2ISA
bridge node.
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here". The node should have a compatible
> property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci node.
Are there any naming conventions (maybe lower case only)?
> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers. I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.
I agree (even if it means more work for me :-)
I'll post a revised version of the device tree.
Thanks!
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-05 5:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905054645.GA26788@localhost.localdomain>
On Wed, 2007-09-05 at 15:46 +1000, David Gibson wrote:
> > > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > > >
> > > > Probably. I just need to find out where they are stored.
> > >
> > > It's not buried somewhere in the arch/ppc/boot code?
> >
> > It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> > I'd rather avoid. But I did find where it's stored in flash, so I can
> > read it from there. I just need to do a little more work to get it in a
> > manner that can be used.
>
> Hrm.. is that address actually guaranteed to be stable across PIBS
> versions? If arch/ppc uses __res, I think we should do that too. It
> shouldn't be any worse than what we already do fot cuboot.
The address should be stable for all versions of PIBS that come on the
Bamboo boards, yes. And after looking at it a bit more, the wrapper in
arch/ppc for PIBS essentially mocks up __res by reading the values out
of flash. So the way I'm doing it is the way it was already done.
josh
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-05 13:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070905114023.GA4072@localhost.localdomain>
On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > The kernel is of course welcome to do so -- and this may be a valid
> > reason to attach pin information to specific device nodes, if it actually
> > saves a non-negligible amount of power -- but it's not a reason to force
> > the kernel to have to care by not setting things up in the firmware.
>
> Well, I might agree here. But to me it seems unnatural that I have to
> upgrade bootloader to use SPI -- I can already boot the kernel.
Sure -- the firmware should have been done right the first time.
Unfortunately, it very often doesn't, and thus fixups in the kernel's
platform code are warranted, but the firmware is still the preferred
place to do it.
> Bootloader's duties are finished when kernel booted.
And this line of thinking is what causes boards to be shipped with
half-assed firmware. :-)
-Scott
^ permalink raw reply
* Re: Breakpoint is not hitting for Kernel Debugging
From: Detlev Zundel @ 2007-09-05 13:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7c1681440709032107u3feb0684x34dcf44b5e43616@mail.gmail.com>
Hi,
> Try adding this line to your BDI config to clear/invalidate the page
> table base address so that the MMU translation works before the MMU
> has been initialised.
>
> ;; Following is to clear the page table base address
> WM32 0x000000f0 0x00000000
Did you really need this under any circumstance? To only hit a
breakpoint?
I am asking because recent experiences with BDI debugging showed that
there are some pitfalls that one can fall into (and these are only the
ones that I got aware of):
a) - PTBASE is 0x00 (!) for head_fsl_booke, head_44x,
- PTBASE is 0xf0 for head_4xx
Don't ask me if this makes any sense, but that's how it is right
now.
So for the original poster I would say a PTBASE 0x0 would be in
order.
b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
start_kernel just fine by only subtracting 0xc0000000 (using a
"default" translation) - it was only later (debugging dynamic
modules) that the wrong PTBASE hit me hard.
What proved very useful for me is the bdi command "phys <addr>" to
check the translation the BDI uses [you can use the command (as all
BDI commands) through gdb with "mon phys <addr>" btw.] - a wrong
PTBASE led to subsequent "JTAG instruction overruns" so I was pretty
sure that this was my real problem.
Best wishes
Detlev
--
The limits of my language stand for the limits of my world.
-- Ludwig Wittgenstein
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: ppc Floating Point support status
From: Kumar Gala @ 2007-09-05 14:11 UTC (permalink / raw)
To: Ben Buchli; +Cc: linuxppc-dev
In-Reply-To: <200709040940.04801.bbuchli@xes-inc.com>
On Sep 4, 2007, at 9:40 AM, Ben Buchli wrote:
> On Wednesday 22 August 2007 15:52:09 Kumar Gala wrote:
>> On Aug 22, 2007, at 1:37 PM, Ben Buchli wrote:
>>> Hello everybody,
>>> I was wondering what the status was on supporting floating-point
>>> instructions
>>> for the mpc8548. I found the suggested patch:
>>> http://patchwork.ozlabs.org/linuxppc/patch?
>>> order=patch&filter=none&id=9455,
>>> but I'm not sure for what kernel version this is and when it will be
>>> officially supported.
>>>
>>> Thanks a lot for your help!
>>>
>>> Please CC to me (bbuchli at xes-inc.com) as I haven't subscribed to
>>> this list.
>>
>> I thing these are still up in the air based on having some sense of
>> testing related to them.
>>
>> - k
>
> Kumar,
> thanks for getting back with me.
> We're doing some early performance testing on one of our boards
> with an
> mpc8548e. I was wondering if there's a snapshot available that we
> could use
> and maybe do some working/testing on.
> Thanks a lot.
I'm confused as to what you are looking for. Is 2.6.23-rc5 not
sufficient?
- k
^ permalink raw reply
* Re: PCI:cannot allocate resource region 0 of device 0001:01:00.0?
From: Kumar Gala @ 2007-09-05 14:14 UTC (permalink / raw)
To: dnl; +Cc: linuxppc-embedded
In-Reply-To: <F3D55679E1DCFF49A57570501B70475F070D83BB@CL5EXBE04.ad2.softcom.biz>
On Sep 3, 2007, at 8:45 AM, dnl wrote:
>
> Hi all,
>
> I using Montavista kernel for custom MPC8555CDS board and one PCI
> slot on the Board.
>
> When my kernel boots i am getting the following Messages :
>
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 0 of device 0001:01:00.0
> PCI: Cannot allocate resource region 1 of device 0001:01:00.0
> PCI: Failed to allocate mem resource #1:80000000@0 for 0001:01:00.
>
> please find attached Kernel boot messages and corresponding pci
> directory after kernel boots.
> could anyone face similar problem?
You'll need to take up MV kernel issues up with MV.
- k
^ permalink raw reply
* [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Olof Johansson @ 2007-09-05 14:27 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, akpm, linux-pcmcia, hch
Convert the io_req_t members to kio_addr_t, to allow use on machines with
more than 16 bits worth of IO port address space (ppc64 in this case,
but it applies to others as well).
Signed-off-by: Olof Johansson <olof@lixom.net>
---
I'm not at home in the PCMCIA stack, so I'd appreciate some extra eyes
on it to avoid regressions. As far as I can tell, the io_req_t structure
is not exported through any userspace interface and only used internally.
This supersedes the earlier (rejected) "increase ioaddr_t to 32-bits"
patch (http://patchwork.ozlabs.org/linuxppc/patch?id=11908) for ppc64,
since with this change that would not be needed.
Thanks,
Olof
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index 0ce39de..585c14b 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -65,8 +65,8 @@ extern int ds_pc_debug;
* Special stuff for managing IO windows, because they are scarce
*/
-static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
- ioaddr_t num, u_int lines)
+static int alloc_io_space(struct pcmcia_socket *s, u_int attr, kio_addr_t *base,
+ kio_addr_t num, u_int lines)
{
int i;
kio_addr_t try, align;
@@ -74,14 +74,14 @@ static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
align = (*base) ? (lines ? 1<<lines : 0) : 1;
if (align && (align < num)) {
if (*base) {
- ds_dbg(s, 0, "odd IO request: num %#x align %#lx\n",
+ ds_dbg(s, 0, "odd IO request: num %#lx align %#lx\n",
num, align);
align = 0;
} else
while (align && (align < num)) align <<= 1;
}
if (*base & ~(align-1)) {
- ds_dbg(s, 0, "odd IO request: base %#x align %#lx\n",
+ ds_dbg(s, 0, "odd IO request: base %#lx align %#lx\n",
*base, align);
align = 0;
}
@@ -132,8 +132,8 @@ static int alloc_io_space(struct pcmcia_socket *s, u_int attr, ioaddr_t *base,
} /* alloc_io_space */
-static void release_io_space(struct pcmcia_socket *s, ioaddr_t base,
- ioaddr_t num)
+static void release_io_space(struct pcmcia_socket *s, kio_addr_t base,
+ kio_addr_t num)
{
int i;
diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h
index d5838c3..657d653 100644
--- a/include/pcmcia/cs.h
+++ b/include/pcmcia/cs.h
@@ -147,11 +147,11 @@ typedef struct config_req_t {
/* For RequestIO and ReleaseIO */
typedef struct io_req_t {
- ioaddr_t BasePort1;
- ioaddr_t NumPorts1;
+ kio_addr_t BasePort1;
+ kio_addr_t NumPorts1;
u_int Attributes1;
- ioaddr_t BasePort2;
- ioaddr_t NumPorts2;
+ kio_addr_t BasePort2;
+ kio_addr_t NumPorts2;
u_int Attributes2;
u_int IOAddrLines;
} io_req_t;
^ permalink raw reply related
* Re: Breakpoint is not hitting for Kernel Debugging
From: Dan Malek @ 2007-09-05 16:31 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linuxppc-embedded
In-Reply-To: <m2wsv58cp1.fsf@ohwell.denx.de>
On Sep 5, 2007, at 6:27 AM, Detlev Zundel wrote:
> Hi,
>
>> ;; Following is to clear the page table base address
>> WM32 0x000000f0 0x00000000
>
> Did you really need this under any circumstance? To only hit a
> breakpoint?
No, you don't. For the identify mapped kernel
space, only the MMU XLAT is required, which
covers nearly all kernel. This is only necessary for
tracking vmalloc()'ed space, like for loadable
modules.
However, this WM32 should not be necessary
in any case, as the page table pointers for
BDI information tracking are set up by the
kernel initialization functions.
> I am asking because recent experiences with BDI debugging showed that
> there are some pitfalls that one can fall into (and these are only the
> ones that I got aware of):
Yes, and I apologize for not allocating the
time to work with Abatron to make this
work better. The page tables changes
that have taken (and still take) place in
2.6 caused our original 2.4 implementation
to not work well. Abatron has made updates
that work well, but there are still some edge
cases that may not work well. I need to find
those and provide some assistance.
The whole of the Linux BDI configuration
has been abused as well, the BDI_SWITCH
should not be used as it is today. That
was not the intention for this particular
configuration option.
> So for the original poster I would say a PTBASE 0x0 would be in
> order.
It changes a little among the processor variants,
in particular traditional Power versus Book E.
Check the release notes and manuals for the
BDI2000, along with the information from
Ultimate Solutions to determine what is best.
> b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
> start_kernel just fine by only subtracting 0xc0000000 (using a
> "default" translation) - it was only later (debugging dynamic
> modules) that the wrong PTBASE hit me hard.
That's correct. If the BDI firmware can find the
translation in the TLB, it will just use that. In the
case of many processors, this is either a wired
entry or a BAT. If the BDI firmware can't find
a valid translation, it walks the page tables.
For 8xx and some 40x, the PTBASE is required
as there may be no wired entries by default.
Just remember that the values for both MMU XLAT
and PTBASE must match the kernel software and
configuration. This is the only correct answer :-)
Documentation will describe the public source,
default configuration at the time of the writing,
but it's very easy to change and will cause
debugging problems.
Thanks.
-- Dan
^ permalink raw reply
* Re: disable interrput under ppc?
From: Scott Wood @ 2007-09-05 16:31 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <200709051000.46281.wangbj@lzu.edu.cn>
On Wed, Sep 05, 2007 at 10:00:46AM +0800, Wang, Baojun wrote:
> hw_enable_irq() and hw_disable_irq() is exactly the same as
> local_irq_enable()/local_irq_disable(), but the output shows while running
> hw_eable_irq() (at that point irq is disabled), the rest of the code is
> blocked, and I don't know why:
>
> output:
> [ 172.049381] sync_root_events: looping!
> [ 172.053159] sync_root_events: looping 2!
> [ 172.057094] sync_root_events: looping 3!
> [ 172.061027] hw_irq_disabled?: 1
> [ 172.997338] sync_root_events: looping!
> [ 173.001095] sync_root_events: looping 2!
> [ 173.005028] sync_root_events: looping 3!
> [ 173.008961] hw_irq_disabled?: 1
What did you expect the output to be? I assume that you're taking an
interrupt after you enable interrupts?
-Scott
^ permalink raw reply
* [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-05 16:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <412bb2e63637100c8d47595a19f888ae@kernel.crashing.org>
Updated DTS below
Device tree source file for the PPC405 Walnut evaluation board.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/walnut.dts | 183 +++++++++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -0,0 +1,183 @@
+/*
+ * Device Tree Source for IBM Walnut
+ *
+ * Copyright 2007 IBM Corp.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "ibm,walnut";
+ compatible = "ibm,walnut";
+ dcr-parent = <&/cpus/PowerPC,405GP@0>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,405GP@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <bebc200>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>;
+ d-cache-size = <4000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 9>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ plb {
+ compatible = "ibm,plb3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL: mcmal {
+ compatible = "ibm,mcmal-405gp", "ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <1>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405gp", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <ef600000 ef600000 a00000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <2580>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <2580>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC: i2c@ef600500 {
+ compatible = "ibm,iic-405gp", "ibm,iic";
+ reg = <ef600500 11>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ GPIO: gpio@ef600700 {
+ compatible = "ibm,gpio-405gp";
+ reg = <ef600700 20>;
+ };
+
+ EMAC: ethernet@ef600800 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405gp", "ibm,emac";
+ interrupt-parent = <&UIC0>;
+ interrupts = <9 4 f 4>;
+ reg = <ef600800 70>;
+ mal-device = <&MAL>;
+ mal-tx-channel = <0 1>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000001>;
+ };
+
+ };
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405gp", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ sram@0,0 {
+ reg = <0 0 80000>;
+ };
+
+ flash@0,80000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "JEDEC";
+ bank-width = <1>;
+ partitions = <0 80000>;
+ partition-names = "OpenBIOS";
+ reg = <0 80000 80000>;
+ };
+
+ ds1743@1,0 {
+ /* NVRAM and RTC */
+ compatible = "ds1743";
+ reg = <1 0 2000>;
+ };
+
+ keyboard@2,0 {
+ compatible = "intel,82C42PC";
+ reg = <2 0 2>;
+ };
+
+ ir@3,0 {
+ compatible = "ti,TIR2000PAG";
+ reg = <3 0 10>;
+ };
+
+ fpga@7,0 {
+ compatible = "Walnut-FPGA";
+ reg = <7 0 10>;
+ virtual-reg = <f0300005>;
+ };
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@ef600300";
+ };
+};
^ 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