* Re: Question on mpc52xx_common.c
From: Scott Wood @ 2008-04-08 20:07 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20080408194517.GX13814@pengutronix.de>
Robert Schwebel wrote:
> Well observed; isn't this the prove of the assumption that the whole
> device tree idea is not working? It is *always* inconsistent and it is
> *maintenance hell* because out-of-tree ports do *always* breakt because
> of string inconsistencies. We have just ported a 8260 board from 2.6.22
> to 2.6.25 and it is almost 100% oftree porting.
There's going to be more churn in the initial stages than down the road.
82xx had barely been added to arch/powerpc in 2.6.22, and there was
little review of the initial device tree bindings.
> The ARM method of using just a device number is so much easier ...
Yeah, it's so much fun to have to allocate a globally unique number for
every minor tweak of a board, and to have to maintain a mapping from
said numbers to information that is semantically equivalent to a device
tree but in less maintainable form in the kernel source.
-Scott
^ permalink raw reply
* Re: Question on mpc52xx_common.c
From: Robert Schwebel @ 2008-04-08 19:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804080752g595196det8f576df1884bac5d@mail.gmail.com>
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
> It may be ideal, but I don't think it is realistic. I'm now of the
> firm opinion that device trees and firmware are *never* perfect.
> Especially when the definition of perfect is a moving target.
Well observed; isn't this the prove of the assumption that the whole
device tree idea is not working? It is *always* inconsistent and it is
*maintenance hell* because out-of-tree ports do *always* breakt because
of string inconsistencies. We have just ported a 8260 board from 2.6.22
to 2.6.25 and it is almost 100% oftree porting. And you do not even have
a single point of a parser, because all this string parsing is
completely scattered all over the tree.
The ARM method of using just a device number is so much easier ...
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: André Schwarz @ 2008-04-08 19:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080408164853.GH2552@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
Scott Wood wrote:
> On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
>
>> after building a debug kernel and attaching the bdi2000 it looks like
>> the crash occurs during "console_init()" ...
>>
>
> Does your device tree have a /chosen node after u-boot is done with it?
> find_legacy_serial_ports() can crash otherwise (we really should fix that).
>
>
latest u-boot does add the chosen node.
As far as I know it's for initrd setup ... don't know if it's complete.
>> Since we're using a dtb I omit the "console=..." argument for the
>> kernel. Is this correct ?
>>
>
> It's OK if you have /chosen/linux,stdout-path.
>
>
that sounds promising ! Haven't seen this and will have a closer look.
>> If "console=/dev/ttyS0,115200N8" argument is given the serial console
>> stops working after console_init....
>>
>>
>> On other PowerPC system I could see something like this during boot :
>>
>> -> find_legacy_serial_port()
>> stdout is /soc8568@e0000000/serial@4600
>> legacy_serial_console = 1
>> default console speed = 115340
>> <- find_legacy_serial_port()
>>
>>
>> Should I see this message also ?
>>
>
> Only if you enable debug messages in legacy_serial.c.
>
>
ok.
>> Have I misconfigured anything ?
>>
>
> One thing that sticks out from the above is that you ask for ttyS0, but the
> stdout you list from the other system corresponds to ttyS1. Is this just a
> difference between the two systems?
>
>
Yes - the log from the MPC8568 is a copy&paste from another posting.
It's not my system.
I want ttyS0.
> -Scott
>
I appreciate your help !
Thanks,
André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 2914 bytes --]
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] [v5] Add idle wait support for 44x platforms
From: Hollis Blanchard @ 2008-04-08 19:43 UTC (permalink / raw)
To: kvm-ppc-devel; +Cc: linuxppc-dev
In-Reply-To: <df0f79b7b4ab628887c2.1207673354@thinkpadL>
On Tuesday 08 April 2008 11:49:14 Jerone Young wrote:
> 2 files changed, 77 insertions(+), 1 deletion(-)
> arch/powerpc/platforms/44x/Makefile | 2
> arch/powerpc/platforms/44x/idle.c | 76
> +++++++++++++++++++++++++++++++++++
>
>
> Updates: Now setting MSR_WE is now default
> Tested on hardware platforms bamboo & sequioa and appears
> things are working fine on actually hardware!
>
> This patch adds the ability for the CPU to go into wait state while in
> cpu_idle loop. This helps virtulization solutions know when the guest Linux
> kernel is in an idle state. There are two ways to do it.
>
> Command line
> idle=spin <-- CPU will spin
> idle=wait <-- set CPU into wait state when idle (default)
>
>
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
Acked-by: Hollis Blanchard <hollisb@us.ibm.com>
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] tg3: fix for PPC 44x platforms
From: Sergei Shtylyov @ 2008-04-08 19:33 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
The driver stores the the PCI resource addresses into 'unsigned long' variable
before calling ioremap() on them. This warrants kernel oops when the registers
are accesse on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion of the
PCI I/O and memory resources are mapped below 4 GB, but arch/powerpc/ code got
rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
This is the same issue as the one that has been recently addressed by commits
3c34ac36ac1084e571ef9b6fb1d6a5b10ccc1fd0 (e1000: Fix for 32 bits platforms with
64 bits resources) and c976816b6e901341ec3c4653147316c15549a1c4 (siimage: fix
kernel oops on PPC 44x). The patch has only been compile tested though...
drivers/net/tg3.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/net/tg3.c
===================================================================
--- linux-2.6.orig/drivers/net/tg3.c
+++ linux-2.6/drivers/net/tg3.c
@@ -12578,7 +12578,8 @@ static int __devinit tg3_init_one(struct
const struct pci_device_id *ent)
{
static int tg3_version_printed = 0;
- unsigned long tg3reg_base, tg3reg_len;
+ resource_size_t tg3reg_base;
+ unsigned long tg3reg_len;
struct net_device *dev;
struct tg3 *tp;
int err, pm_cap;
^ permalink raw reply
* [PATCH] natsemi: fix for PPC 44x platforms
From: Sergei Shtylyov @ 2008-04-08 19:31 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
The driver stores the the PCI resource address into 'unsigned long' variable
before calling ioremap() on it. This warrants kernel oops when the registers
are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion of the
PCI I/O and memory resources are mapped below 4 GB, but arch/powerpc/ code got
rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
This is the same issue as the one that has been recently addressed by commits
3c34ac36ac1084e571ef9b6fb1d6a5b10ccc1fd0 (e1000: Fix for 32 bits platforms with
64 bits resources) and c976816b6e901341ec3c4653147316c15549a1c4 (siimage: fix
kernel oops on PPC 44x). The patch has only been compile tested though...
drivers/net/natsemi.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/net/natsemi.c
===================================================================
--- linux-2.6.orig/drivers/net/natsemi.c
+++ linux-2.6/drivers/net/natsemi.c
@@ -786,7 +786,8 @@ static int __devinit natsemi_probe1 (str
struct netdev_private *np;
int i, option, irq, chip_idx = ent->driver_data;
static int find_cnt = -1;
- unsigned long iostart, iosize;
+ resource_size_t iostart;
+ unsigned long iosize;
void __iomem *ioaddr;
const int pcibar = 1; /* PCI base address register */
int prev_eedata;
@@ -946,9 +947,9 @@ static int __devinit natsemi_probe1 (str
goto err_create_file;
if (netif_msg_drv(np)) {
- printk(KERN_INFO "natsemi %s: %s at %#08lx "
+ printk(KERN_INFO "natsemi %s: %s at %#08llx "
"(%s), %s, IRQ %d",
- dev->name, natsemi_pci_info[chip_idx].name, iostart,
+ dev->name, natsemi_pci_info[chip_idx].name, (u64)iostart,
pci_name(np->pci_dev), print_mac(mac, dev->dev_addr), irq);
if (dev->if_port == PORT_TP)
printk(", port TP.\n");
^ permalink raw reply
* Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Kamalesh Babulal @ 2008-04-08 17:45 UTC (permalink / raw)
To: Paul Mackerras
Cc: kernel list, linuxppc-dev, linux-next, nacc, Andrew Morton,
Balbir Singh
In-Reply-To: <18427.27360.30297.84859@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The kernel oops after applying the patch. Some time it takes more than
>> one run to reproduce it, it was reproducible in the second run this
>> time.
>>
>> Unrecoverable exception 4100 at c000000000008c8c
>> Oops: Unrecoverable exception, sig: 6 [#1]
>> SMP NR_CPUS=128 NUMA pSeries
>> Modules linked in:
>> NIP: c000000000008c8c LR: 000000000ff0135c CTR: 000000000ff012f0
>> REGS: c000000772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest)
>> MSR: 8000000000001030 <ME,IR,DR> CR: 44044228 XER: 00000000
>> TASK = c00000077cfa0900[13437] 'cc1' THREAD: c000000772340000 CPU: 2
>> GPR00: 0000000000004000 c000000772343e30 00000000000000bb 000000000000d032
>> GPR04: 00000000000000bb 0000000000000400 000000000000000a 0000000000000002
>> GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR12: 0000000000000000 c000000000734000 0000000000000064 00000000ffe6df08
>> GPR16: 00000000105b0000 00000000105b0000 0000000010440000 00000000105b0000
>> GPR20: 00000000ffe6e008 00000000105b0000 00000000105b0000 000000000000000a
>> GPR24: 000000000ffec408 0000000000000001 00000000ffe6ddca 0000000000000400
>> GPR28: 000000000ffec408 00000000f7ff8000 000000000ffebff4 0000000000000400
>> NIP [c000000000008c8c] restore+0x8c/0xc0
>> LR [000000000ff0135c] 0xff0135c
>> Call Trace:
>> [c000000772343e30] [c000000000008cd4] do_work+0x14/0x2c (unreliable)
>> Instruction dump:
>> 7c840078 7c810164 70604000 41820028 60000000 7c4c42e6 e88d01f0 f84d01f0
>> 7c841050 e84d01e8 7c422214 f84d01e8 <e9a100d8> 7c7b03a6 e84101a0 7c4ff120
>>
<snip>
> The exception happened at c...8c8c but you looked at c...8cdc with
> gdb. What's at c...8c8c?
>
>> please let me know if you need more information.
>
> The .config would be useful, but don't spam everyone on cc with it,
> just send it to me privately.
>
> Paul.
Hi Paul,
Similar call trace was seen in 2.6.24-rc3-git2 kernel while bootup, I have attached the
boot log to bugzilla (http://bugzilla.kernel.org/attachment.cgi?id=15666&action=view).
When looking for the last good one, we found that the kernel oops seems to be reproducible
from the 2.6.24-rc8-git3 kernel onwards.
Thanks to nishanth for pointing it out, Please let me know if you need more information.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] [v5] Add idle wait support for 44x platforms
From: Jerone Young @ 2008-04-08 16:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/idle.c | 76 +++++++++++++++++++++++++++++++++++
Updates: Now setting MSR_WE is now default
Tested on hardware platforms bamboo & sequioa and appears
things are working fine on actually hardware!
This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it.
Command line
idle=spin <-- CPU will spin
idle=wait <-- set CPU into wait state when idle (default)
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young <jyoung5@us.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <asm/machdep.h>
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = "wait", .entry = &ppc44x_idle },
+ { .name = "spin", .entry = NULL },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param("idle", idle_param);
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-08 16:48 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FB7822.6090401@matrix-vision.de>
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
> after building a debug kernel and attaching the bdi2000 it looks like
> the crash occurs during "console_init()" ...
Does your device tree have a /chosen node after u-boot is done with it?
find_legacy_serial_ports() can crash otherwise (we really should fix that).
> Since we're using a dtb I omit the "console=..." argument for the
> kernel. Is this correct ?
It's OK if you have /chosen/linux,stdout-path.
> If "console=/dev/ttyS0,115200N8" argument is given the serial console
> stops working after console_init....
>
>
> On other PowerPC system I could see something like this during boot :
>
> -> find_legacy_serial_port()
> stdout is /soc8568@e0000000/serial@4600
> legacy_serial_console = 1
> default console speed = 115340
> <- find_legacy_serial_port()
>
>
> Should I see this message also ?
Only if you enable debug messages in legacy_serial.c.
> Have I misconfigured anything ?
One thing that sticks out from the above is that you ask for ttyS0, but the
stdout you list from the other system corresponds to ttyS1. Is this just a
difference between the two systems?
-Scott
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Scott Wood @ 2008-04-08 16:43 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linuxppc-dev
In-Reply-To: <47FB3206.7080406@matrix-vision.de>
On Tue, Apr 08, 2008 at 10:51:18AM +0200, Andre Schwarz wrote:
> Call Trace:
> [c01f9ef0] [c001c190] (unreliable)
> [c01f9f10] [c0140c84]
> [c01f9f20] [c0140ccc]
> [c01f9f40] [c014145c]
> [c01f9f60] [c0014014]
> [c01f9fa0] [c01d1a40]
> [c01f9fb0] [c01ce64c]
> [c01f9fc0] [c01c55ac]
> [c01f9ff0] [00003438]
Please turn kallsyms on, which will produce an annotated call trace. Not
all these addresses were in the System.map fragment.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Scott Wood @ 2008-04-08 16:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, hollisb, linuxppc-dev
In-Reply-To: <8C415339-5DB0-42B3-A942-17296DE68267@kernel.crashing.org>
On Tue, Apr 08, 2008 at 09:28:12AM -0500, Kumar Gala wrote:
> On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
>> As far as the above is concerned, I'm not too fan of fixed virtual
>> addresses. I'd rather dynamically assign it. But we can do it.
>
> I'm in agreement with Ben here. On Freescale parts that could mean
> using up to 16M of virtual address space while in reality we may only
> need a handful of 4k pages to cover SoC registers that we are truly
> accessing at runtime.
So make it configurable, and turn it off if you're low on address space.
Most of the time, I'd think saving TLB0 entries would be more beneficial,
especially with heavy I/O workloads where registers get banged on a lot.
It's the early debugging that I'm really concerned with, though. It gets
old hacking an early mapping in each time.
-Scott
^ permalink raw reply
* Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc
From: Johannes Berg @ 2008-04-08 16:04 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20080407171428.GA14900@farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
On Mon, 2008-04-07 at 10:14 -0700, Dale Farnsworth wrote:
> Add the low level irq tracing hooks for 32-bit powerpc needed
> to enable full lockdep functionality.
>
> Dale Farnsworth <dale@farnsworth.org>
> ---
> This version fixes the clobbering of r12 by the call to
> trace_hardirqs_off() that was pointed out by BenH.
>
> Johannes, I'd appreciate your trying this version if/when
> you get the chance.
Thanks Dale, this version seems to work. I'll stress it a bit more
later, but so far it has survived *much* longer than both previous
versions.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Tejun Heo @ 2008-04-08 15:03 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, gregkh, linux-kernel, linux-ide, jgarzik, alan
In-Reply-To: <47FB8751.3040301@ru.mvista.com>
Sergei Shtylyov wrote:
>> Yeah, right please go ahead. But I wonder whether any BIOS was
>> actually crazy enough to map mmio region above 4G on 32bit machine.
>
> This is a *hardware* mapping on some non-x86 platforms (like PPC 44x
> or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special
> hooks called from ioremap() which help create an illusion that the PCI
> memory space on such platforms (not only it) is mapped below 4 GB;
> arch/powerpc/ kernel doesn't do this anymore -- hence this newly
> encountered issue.
Ah... I see. Thanks for the clarification.
--
tejun
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Sergei Shtylyov @ 2008-04-08 14:55 UTC (permalink / raw)
To: Tejun Heo; +Cc: linuxppc-dev, gregkh, linux-kernel, linux-ide, jgarzik, alan
In-Reply-To: <47FB85CB.2070506@gmail.com>
Tejun Heo wrote:
>> A very late comment but nevertheless... :-)
> Better late than never.
:-)
>> Those functions are going to break on 32-bit platforms with
>> extended physical address (well, that's starting with Pentiums which
>> had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x).
>> You should have used resource_size_t for the 'offset' parameter. As
>> this most probably means that libata is broken on such platforms, I'm
>> going to submit a patch...
It's broken with drivers using MMIO, I meant to say.
> Yeah, right please go ahead. But I wonder whether any BIOS was actually
> crazy enough to map mmio region above 4G on 32bit machine.
This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or
MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called
from ioremap() which help create an illusion that the PCI memory space on such
platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do
this anymore -- hence this newly encountered issue.
WBR, Sergei
^ permalink raw reply
* Re: Question on mpc52xx_common.c
From: Grant Likely @ 2008-04-08 14:52 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Raquel and Bill
In-Reply-To: <47FB3CD6.2090706@genesi-usa.com>
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey <matt@genesi-usa.com> wrote:
> I'd not thank Grant.
>
> I think the prom_init fixes are bordering on disgusting.. it would
> make it's way into commercial code for sure, but only because nobody
> would see what a hideous mess it is :)
>
> The best solution by far is to release a new firmware with the
> device tree fixed. The script method is just not tolerated by users,
> and patching the Linux kernel to keep track with broken firmwares
> is exactly what we hoped to AVOID with Aura in the first place.
It may be ideal, but I don't think it is realistic. I'm now of the
firm opinion that device trees and firmware are *never* perfect.
Especially when the definition of perfect is a moving target.
There are certainly a number of things that are wrong and missing in
the Efika device tree, but in the long run it is proof that the design
of OF and the device tree is good. The tree is unique. Linux and
other OSes can derive the information they need. Current Linux
drivers want data in a way slightly different from the way the Efika
offers it; some of that is Efika's fault, some of that is the driver's
fault, but OF provides the ability to massage the data and ensure the
board will boot.
As of right now; Linux support for the Efika contains only 4 distinct fixups:
1. Change device_type property of the / node from "chrp" to "efika".
Linux will run the wrong initialization code if this is "chrp"
2. change the format of the bestcomm interrupts property. The Linux
drivers wants a list of interrupts and kind of treats the bestcomm
engine as it's own interrupt controller. I think this was probably a
design flaw on the Linux driver, but it is what we currently have.
3. the /builtin/sound node is missing an interrupts property
4. The FEC driver wants MDIO and PHY nodes to talk to the Ethernet
Phy. This one is big, but it is really just a single fixup.
All the other things that many not be what we *like* in the device
tree are really not serious flaws. Mostly compatible properties are
missing any mfg prefix like 'fsl,'. Of course, as Segher points out,
'fsl,' is better, but doesn't match recommended practice either
because UPPERCASE is supposed to be used with the prefix is the stock
ticker symbol. See? Device tree bindings are never perfect. :-)
Regardless, the drivers deal with it and Linux is happy.
Cheers,
g.
>
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Raquel and Bill wrote:
>
> > Thanks Grant.
> >
> > R&B
> >
> >
> > On Mon, Apr 7, 2008 at 9:25 PM, Grant Likely <grant.likely@secretlab.ca
> <mailto:grant.likely@secretlab.ca>> wrote:
> >
> > On Mon, Apr 7, 2008 at 8:14 PM, Arnd Bergmann <arnd@arndb.de
> >
> > <mailto:arnd@arndb.de>> wrote:
> > > On Tuesday 08 April 2008, Matt Sealey wrote:
> > >
> > > > Grant Likely wrote:
> > > > >
> > > > > Sure, why not? If the firmware has already set it up
> > correctly and no
> > > > > devices using it are in use, then the kernel should be okay.
> > :-)
> > > > > That said, I can't imagine choosing to not put the cdm node
> > into the
> > > > > device tree.
> > > >
> > > > *ahem* Efika.
> > >
> > > Maybe we should just give up on making the efika boot with its
> > regular
> > > device tree and instead add a boot wrapper that either fixes up the
> > > data provided by its firmware or just adds a proper dt blob?
> >
> > Current kernels boot the Efika without any firmware scripts.
> > prom_init.c is able to handle the few fixups that the kernel really
> > wants to see. (So life is mostly happy in Efika land now. :-)
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org <mailto:Linuxppc-dev@ozlabs.org>
> >
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> >
> >
> > --
> > http://bbrv.blogspot.com/
> >
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/13] devres: implement managed iomap interface
From: Tejun Heo @ 2008-04-08 14:48 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, gregkh, linux-kernel, linux-ide, jgarzik, alan
In-Reply-To: <47FA4FD2.8060808@ru.mvista.com>
Sergei Shtylyov wrote:
> A very late comment but nevertheless... :-)
Better late than never.
> Those functions are going to break on 32-bit platforms with extended
> physical address (well, that's starting with Pentiums which had 36-bit
> PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should
> have used resource_size_t for the 'offset' parameter. As this most
> probably means that libata is broken on such platforms, I'm going to
> submit a patch...
Yeah, right please go ahead. But I wonder whether any BIOS was actually
crazy enough to map mmio region above 4G on 32bit machine.
--
tejun
^ permalink raw reply
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Kumar Gala @ 2008-04-08 14:28 UTC (permalink / raw)
To: benh; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras, hollisb
In-Reply-To: <1207612292.10388.494.camel@pasglop>
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote:
>>
>> Another possible use is a BAT/TLB1 mapping for SoC registers (or
>> anything
>> else on the board which is frequently accessed), which can be reused
>> by
>> ioremap() to avoid wasting normal TLB entries, and to facilitate
>> early
>> debugging.
>
> As far as the above is concerned, I'm not too fan of fixed virtual
> addresses. I'd rather dynamically assign it. But we can do it.
I'm in agreement with Ben here. On Freescale parts that could mean
using up to 16M of virtual address space while in reality we may only
need a handful of 4k pages to cover SoC registers that we are truly
accessing at runtime.
However I think there might be some utility to have an early ioremap
mappings for debug.
- k
^ permalink raw reply
* Re: TSEC3/4 broken on MPC8548?
From: Kumar Gala @ 2008-04-08 14:17 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: LinuxPPC-Embedded
In-Reply-To: <47FB75BC.10400@grandegger.com>
On Apr 8, 2008, at 8:40 AM, Wolfgang Grandegger wrote:
> Hello,
>
> in the dts file for the MPC8548CDS the nodes for TSEC3/4 are commented
> out because they seem to be broken:
>
> $ grep broken arch/powerpc/boot/dts/*
> arch/powerpc/boot/dts/mpc8548cds.dts:/* eTSEC 3/4 are currently
> broken
>
> Is it still true?
This was a board issue and not a chip issue. However I'm not sure if
the board issues have been resolved. Hopefully Andy will know.
- k
^ permalink raw reply
* Status of patches (ppc32 mm init clean and 85xx kernel reloc)
From: Kumar Gala @ 2008-04-08 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev list
Paul,
Here's my take on the current status of the patchset:
[POWERPC] bootwrapper: Allow specifying of image physical offset
reworked to look at PHDR (needs linker script update patch). Still
open question on how best to do that (objdump, readelf, C program,
suggestions)
[POWERPC] Remove Kconfig option BOOT_LOAD
should be acceptable.
[POWERPC] Provide access to arch/powerpc include path on ppc64
should be acceptable (desired by others).
[POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
You had some questions about _stext and the PAGE_OFFSET vs
KERNELBASE. Not sure if you are satisfied with the answers.
[POWERPC] Introduce lowmem_end_addr to distiguish from total_lowmem
No comments. Should be straight forward.
[POWERPC] 85xx: Cleanup TLB initialization
Only effects 85xx and I don't have issues with it :)
[POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
No comments. Straight forward patch.
[POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
No comments. Straight forward patch.
[POWERPC] Clean up some linker and symbol usage
No comments. Straight forward patch.
[POWERPC] Move phys_addr_t definition into asm/types.h
I had an open question if the Kconfig for PHYS_64BIT should get set on
PPC64 as well (has not effect).
I reworked the asm/types.h bits to look like:
+#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
+typedef __u64 phys_addr_t;
+#else
+typedef __u32 phys_addr_t;
+#endif
[POWERPC] 85xx: Add support for relocatble kernel (and booting at non-
zero
Should probably get a bit more review.
[POWERPC] Update linker script to properly set physical addresses
You felt LOAD_OFFSET should be (CONFIG_PAGE_OFFSET -
CONFIG_PHYSICAL_START). I disagreed. We need to resolve.
I think we should be able to quickly resolve and get into powerpc-next
all but the '85xx: Add support for relocatable kernel' and
'bootwrapper: Allow specifying of image..' patches. If we can close
on the phys_addr_t and linker script patches that would be great.
thanks
- k
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Andre Schwarz @ 2008-04-08 13:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080407161036.GA2688@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 9163 bytes --]
Scott Wood schrieb:
> On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
>
>> Kernel starts and crashes with "unable to handle kernel paging request @
>> 00000000".
>>
>> After turning debug on in some files I can see that the initrd memory
>> gets reserved and the dtb is parsed correctly.
>> PCI memory/io spaces are set up fine.
>>
>> At first I thought this is a problem with the device tree since the call
>> trace always points to "of_"-functions and "strcmp".
>>
>
> Could you provide this call trace?
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
Scott,
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during "console_init()" ...
Since we're using a dtb I omit the "console=..." argument for the
kernel. Is this correct ?
If "console=/dev/ttyS0,115200N8" argument is given the serial console
stops working after console_init....
On other PowerPC system I could see something like this during boot :
-> find_legacy_serial_port()
stdout is /soc8568@e0000000/serial@4600
legacy_serial_console = 1
default console speed = 115340
<- find_legacy_serial_port()
Should I see this message also ?
Have I misconfigured anything ?
u-boot prints the following dtb :
...
aliases {
name = "aliases";
ethernet0 = "/soc8343@e0000000/ethernet@24000";
ethernet1 = "/soc8343@e0000000/ethernet@25000";
serial0 = "/soc8343@e0000000/serial@4500";
serial1 = "/soc8343@e0000000/serial@4600";
pci0 = "/pci@e0008500";
};
cpus {
name = "cpus";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
PowerPC,8343@0 {
name = "PowerPC,8343";
device_type = "cpu";
reg = <0x00000000>;
d-cache-line-size = <0x00000020>;
i-cache-line-size = <0x00000020>;
d-cache-size = <0x00008000>;
i-cache-size = <0x00008000>;
timebase-frequency = <0x03f940aa>;
bus-frequency = <0x0fe502a8>;
clock-frequency = <0x17d783fc>;
};
};
memory {
name = "memory";
device_type = "memory";
reg = <0x00000000 0x20000000>;
};
soc8343@e0000000 {
name = "soc8343";
#address-cells = <0x00000001>;
#size-cells = <0x00000001>;
device_type = "soc";
compatible = "soc";
ranges = [00 00 00 00 e0 00 00 00 00 10 00 00];
reg = <0xe0000000 0x00000200>;
bus-frequency = <0x0fe502a8>;
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <0x00000200 0x00000100>;
};
i2c@3000 {
name = "i2c";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
cell-index = <0x00000000>;
compatible = "fsl-i2c";
reg = <0x00003000 0x00000100>;
interrupts = <0x0000000e 0x00000008>;
interrupt-parent = <0x00000001>;
dfsrr;
};
i2c@3100 {
name = "i2c";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
cell-index = <0x00000001>;
compatible = "fsl-i2c";
reg = <0x00003100 0x00000100>;
interrupts = <0x0000000f 0x00000008>;
interrupt-parent = <0x00000001>;
dfsrr;
};
spi@7000 {
name = "spi";
cell-index = <0x00000000>;
compatible = "fsl,spi";
reg = <0x00007000 0x00001000>;
interrupts = <0x00000010 0x00000008>;
interrupt-parent = <0x00000001>;
mode = "cpu";
};
usb@22000 {
name = "usb";
compatible = "fsl-usb2-mph";
reg = <0x00022000 0x00001000>;
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
interrupt-parent = <0x00000001>;
interrupts = <0x00000027 0x00000008>;
phy_type = "ulpi";
port0;
};
mdio@24520 {
name = "mdio";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
compatible = "fsl,gianfar-mdio";
reg = <0x00024520 0x00000020>;
ethernet-phy@0 {
cell-index = <0x00000000>;
interrupt-parent = <0x00000001>;
interrupts = <0x00000016 0x00000008>;
reg = <0x00000000>;
device_type = "ethernet-phy";
linux,phandle = <0x00000002>;
};
ethernet-phy@1 {
cell-index = <0x00000001>;
interrupt-parent = <0x00000001>;
interrupts = <0x00000017 0x00000008>;
reg = <0x00000001>;
device_type = "ethernet-phy";
linux,phandle = <0x00000003>;
};
};
ethernet@24000 {
cell-index = <0x00000000>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x00024000 0x00001000>;
local-mac-address = [b6 b4 45 eb fb c0];
interrupts = [00 00 00 20 00 00 00 08 00 00 00
21 00 00 00 08 00 00 00 22 00 00 00 08];
interrupt-parent = <0x00000001>;
phy-handle = <0x00000002>;
linux,network-index = <0x00000000>;
};
ethernet@25000 {
cell-index = <0x00000001>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x00025000 0x00001000>;
local-mac-address = [b6 b4 45 eb fb c2];
interrupts = [00 00 00 23 00 00 00 08 00 00 00
24 00 00 00 08 00 00 00 25 00 00 00 08];
interrupt-parent = <0x00000001>;
phy-handle = <0x00000003>;
linux,network-index = <0x00000001>;
};
serial@4500 {
cell-index = <0x00000000>;
device_type = "serial";
compatible = "ns16550";
reg = <0x00004500 0x00000100>;
clock-frequency = <0x0fe502a8>;
interrupts = <0x00000009 0x00000008>;
interrupt-parent = <0x00000001>;
};
serial@4600 {
cell-index = <0x00000001>;
device_type = "serial";
compatible = "ns16550";
reg = <0x00004600 0x00000100>;
clock-frequency = <0x0fe502a8>;
interrupts = <0x0000000a 0x00000008>;
interrupt-parent = <0x00000001>;
};
pic@700 {
interrupt-controller;
#address-cells = <0x00000000>;
#interrupt-cells = <0x00000002>;
reg = <0x00000700 0x00000100>;
device_type = "ipic";
linux,phandle = <0x00000001>;
};
};
....
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 27183 bytes --]
^ permalink raw reply
* TSEC3/4 broken on MPC8548?
From: Wolfgang Grandegger @ 2008-04-08 13:40 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
in the dts file for the MPC8548CDS the nodes for TSEC3/4 are commented
out because they seem to be broken:
$ grep broken arch/powerpc/boot/dts/*
arch/powerpc/boot/dts/mpc8548cds.dts:/* eTSEC 3/4 are currently broken
Is it still true?
TIA.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] siimage: fix kernel oops on PPC 44x
From: Sergei Shtylyov @ 2008-04-08 13:09 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <200804072330.00610.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
>>Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
>>44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
>>memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
>>that creates an illusion of the PCI I/O and memory resources being mapped below
>>4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having instead
>>CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to 32-bit
>>'unsigned long' type in this driver, and so non-existant memory being ioremap'ed
>>and then accessed...
>>Thanks to Valentine Barshak for providing an initial patch and explanations.
>>Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> applied and pushed to Linus, thanks!
> I guess that it would be worth to audit the rest of IDE code for
Already done. Some drivers, like sgiioc4, scc_pata, and pmac are prone to
that at least in theory. Although I doubt that they ever get used in such
environments as PPC 44x platform kernels, i.e. 32-bit kernel and PCI mapped
beyond 4 GB.
> pci_resource_{start,end}() vs 'unsigned long' occurences and fix them.
There are quite a lot of those overall but they only pose danger if the
resource in question is in memory space since the I/O space always uses
'unsigned long' addresses. So, IDE core and drivers using only I/O resources
should not be prone to that kind of issue.
> [ Even if they work at the moment they are just bugs waiting to happened
> when we add support for some new platforms or rewrite the code... ]
WBR, Sergei
^ permalink raw reply
* Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
From: Paul Mackerras @ 2008-04-08 12:53 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: kernel list, linuxppc-dev, linux-next, nacc, Andrew Morton,
Balbir Singh
In-Reply-To: <47FB5C5A.5020104@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> The kernel oops after applying the patch. Some time it takes more than
> one run to reproduce it, it was reproducible in the second run this
> time.
>
> Unrecoverable exception 4100 at c000000000008c8c
> Oops: Unrecoverable exception, sig: 6 [#1]
> SMP NR_CPUS=128 NUMA pSeries
> Modules linked in:
> NIP: c000000000008c8c LR: 000000000ff0135c CTR: 000000000ff012f0
> REGS: c000000772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest)
> MSR: 8000000000001030 <ME,IR,DR> CR: 44044228 XER: 00000000
> TASK = c00000077cfa0900[13437] 'cc1' THREAD: c000000772340000 CPU: 2
> GPR00: 0000000000004000 c000000772343e30 00000000000000bb 000000000000d032
> GPR04: 00000000000000bb 0000000000000400 000000000000000a 0000000000000002
> GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR12: 0000000000000000 c000000000734000 0000000000000064 00000000ffe6df08
> GPR16: 00000000105b0000 00000000105b0000 0000000010440000 00000000105b0000
> GPR20: 00000000ffe6e008 00000000105b0000 00000000105b0000 000000000000000a
> GPR24: 000000000ffec408 0000000000000001 00000000ffe6ddca 0000000000000400
> GPR28: 000000000ffec408 00000000f7ff8000 000000000ffebff4 0000000000000400
> NIP [c000000000008c8c] restore+0x8c/0xc0
> LR [000000000ff0135c] 0xff0135c
> Call Trace:
> [c000000772343e30] [c000000000008cd4] do_work+0x14/0x2c (unreliable)
> Instruction dump:
> 7c840078 7c810164 70604000 41820028 60000000 7c4c42e6 e88d01f0 f84d01f0
> 7c841050 e84d01e8 7c422214 f84d01e8 <e9a100d8> 7c7b03a6 e84101a0 7c4ff120
>
> (gdb) l *0xc000000000008cdc
> 0xc000000000008cdc is at arch/powerpc/kernel/entry_64.S:608.
> 603 mtmsrd r10,1
> 604
> 605 andi. r0,r4,_TIF_NEED_RESCHED
> 606 beq 1f
> 607 bl .schedule
> 608 b .ret_from_except_lite
> 609
> 610 1: bl .save_nvgprs
> 611 li r3,0
> 612 addi r4,r1,STACK_FRAME_OVERHEAD
The exception happened at c...8c8c but you looked at c...8cdc with
gdb. What's at c...8c8c?
> please let me know if you need more information.
The .config would be useful, but don't spam everyone on cc with it,
just send it to me privately.
Paul.
^ permalink raw reply
* Re: [PATCH] ide: make ide_pci_check_iomem() actually work
From: Sergei Shtylyov @ 2008-04-08 12:38 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <47FB5ADF.20608@ru.mvista.com>
Hi, I just wrote:
>>> This function didn't actually check if a given BAR is in I/O space
>>> because of
>>> using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test
>>> the resource
>>> flags instead of IORESOURCE_IO -- fix this, make ide_hwif_configure()
>>> check the
>>> results failing if necessary, and move the printk() call to the
>>> failure path.
>> This change is OK in itself but I worry that ide_pci_check_iomem() may
>> now
>> return "false" errors (bogus PCI_BASE_ADDRESS_IO_MASK check resulted
>> in MEM
>> resources always surviving ide_pci_check_iomem() calls before the fix)
>> for
>> some host drivers (siimage, scc_pata...) resulting in failed
>> initialization.
> The SiI chips do have normal I/O resources at BAR0..BAR3. As for
> scc_pata, the control should not even get there because BAR0..BAR3 are
> *not* IDE command/control block bases on this chip (BAR0/1 are
> control/DMA bases if you look into setup_mmio_scc()) but they are
> treated as such by the code immediately following ide_pci_check_iomem()
> calls in ide_hwif_configure(), i.e. we might have an error here. The
> same can be said about the PowerMAC driver which has all its MMIO
> registers at BAR0.
>> How's about removing this dead/broken function instead for now?
> If we indeed have a MMIO problem here, it's not in this function but
> in its callers.
Looks like we actually have this problem with scc_pata -- it calls
ide_setup_pci_device() which should lead to calling ide_hwif_configure(). But
this is broken since this call chain expects a normal PCI IDE controller with
BAR0..BAR3 either non-existant or being primary/secondary port bases in I/O space.
>> Thanks,
>> Bart
>>> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
WBR, Sergei
^ permalink raw reply
* Re: Booting a Xilinx board
From: Guillaume Dargaud @ 2008-04-08 12:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <10d401c8995a$1a63beb0$f52f9e86@LPSC0173W>
I'm making progress, thanks in no small part to this list, but I still need
coaching, if you don't mind. The current boot is currently going as such:
loaded at: 00400000 005A819C
board data at: 005A6120 005A619C
relocated to: 00404054 004040D0
zimage at: 00404E40 00515AD1
initrd at: 00516000 005A5AF9
avail ram: 005A9000 08000000
Linux/PPC load: console=ttyUL0,9600 root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.24-rc8-xlnx (guinevere@lpsc6185x.in2p3.fr)
(gcc version 4.1.2) #4 Tue Apr 8 13:41:02 CEST 2008
[ 0.000000] Xilinx Generic PowerPC board support package (Xilinx ML405)
(Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 32768
[ 0.000000] Normal 32768 -> 32768
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 32768
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 32512
[ 0.000000] Kernel command line: console=ttyUL0,9600 root=/dev/ram rw
[ 0.000000] Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[ 0.000224] Console: colour dummy device 80x25
[ 0.001417] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
[ 0.003197] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.039286] Memory: 126804k available (1728k kernel code, 572k data, 104k
init, 0k highmem)
[ 0.132784] Mount-cache hash table entries: 512
[ 0.138698] net_namespace: 64 bytes
[ 0.143763] NET: Registered protocol family 16
[ 0.147717] Registering device uartlite:0
[ 0.148883] Registering device xsysace:0
[ 0.149913] Registering device xilinx_emaclite:0
[ 0.191001] NET: Registered protocol family 2
[ 0.224934] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.228161] TCP established hash table entries: 4096 (order: 3, 32768
bytes)
[ 0.228808] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.229168] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.229201] TCP reno registered
[ 0.241592] checking if image is initramfs...it isn't (no cpio magic);
looks like an initrd
[ 0.854687] Freeing initrd memory: 574k freed
[ 0.855157] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.855208] Call Trace:
[ 0.855227] [c7c17eb0] [c00081b8] show_stack+0x50/0x184 (unreliable)
[ 0.855329] [c7c17ed0] [c0030514] set_fail+0x50/0x68
[ 0.855406] [c7c17ef0] [c0030b7c] sysctl_check_table+0x650/0x698
[ 0.855454] [c7c17f20] [c0030b8c] sysctl_check_table+0x660/0x698
[ 0.855501] [c7c17f50] [c001e874] register_sysctl_table+0x64/0xb4
[ 0.855567] [c7c17f70] [c0231c24] register_ppc_htab_sysctl+0x18/0x2c
[ 0.855629] [c7c17f80] [c022b1e4] kernel_init+0xc8/0x284
[ 0.855667] [c7c17ff0] [c0004b18] kernel_thread+0x44/0x60
[ 0.864221] io scheduler noop registered
[ 0.864277] io scheduler anticipatory registered (default)
[ 0.864302] io scheduler deadline registered
[ 0.864525] io scheduler cfq registered
[ 0.939088] uartlite.0: ttyUL0 at MMIO 0x84000003 (irq = 2) is a uartlite
[ 0.939174] console [ttyUL0] enabled
[ 3.953024] RAMDISK driver initialized: 16 RAM disks of 8192K size 1024
blocksize
[ 4.036331] loop: module loaded
[ 4.067349] xsysace xsa: Xilinx SystemACE revision 1.0.12
[ 4.131096] xsysace xsa: capacity: 1014048 sectors
[ 4.186902] xsa: xsa1 xsa2
[ 4.222849] Xilinx SystemACE device driver, major=254
[ 4.280365] tun: Universal TUN/TAP device driver, 1.6
[ 4.340667] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 4.416748] xilinx_emaclite xilinx_emaclite.0: MAC address is now 2: 0:
0: 0: 0: 0
[ 4.506421] xilinx_emaclite xilinx_emaclite.0: using fifo mode.
[ 4.580452] xilinx_emaclite xilinx_emaclite.0: Xilinx EMACLite at
0x81000000 mapped to 0xC9020000, irq=0
[ 4.691953] mice: PS/2 mouse device common for all mice
[ 4.753483] TCP cubic registered
[ 4.791772] NET: Registered protocol family 1
[ 4.843849] NET: Registered protocol family 17
[ 4.897987] RPC: Registered udp transport module.
[ 4.953147] RPC: Registered tcp transport module.
[ 5.011138] RAMDISK: Compressed image found at block 0
[ 5.905538] VFS: Mounted root (ext2 filesystem).
[ 5.945703] Freeing unused kernel memormdev: /etc/mdev.conf: No such file
or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mdev: /etc/mdev.conf: No such file or directory
mount: mounting configfs on /config failed: No such device
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
And then it stops, although I still have echo when I type.
Now there's no /etc/mdev.conf file in my root fylesystem and I understand I
need to create the devices.
I've been reading docs/mdev.txt and
http://www.lfs-matrix.org/clfs/view/clfs-embedded/mips/bootscripts/mdev.html
and I'm a bit confused.
- do the devices need to be created in the FS before building the ramdisk
and subsequent ACE file ?
- are they created dynamically by /bin/mdev on boot based on a manually
written /etc/mdev.conf table as the error messages seem to imply ?
- can they be generated automagically by a MAKEDEV script ?
In the second case, how do I know which devices and what names I'm supposed
to define ?
--
Guillaume Dargaud
http://www.gdargaud.net/Climbing/
^ 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