* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: David Gibson @ 2008-04-08 2:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, John Linn, Arnd Bergmann
In-Reply-To: <1207406756.6809.2.camel@vader.jdub.homelinux.org>
On Sat, Apr 05, 2008 at 09:45:56AM -0500, Josh Boyer wrote:
> On Thu, 2008-04-03 at 06:16 +0200, Arnd Bergmann wrote:
> > On Thursday 03 April 2008, Grant Likely wrote:
> > > >
> > > > Since it is not really compatible with ns16550, shouldn't you at least specify
> > > > a different "compatible" property? That way, the driver won't do incorrect
> > > > accesses when you try to use an old driver with a device tree that specifies
> > > > one of these.
> > >
> > > Heh; we've gone back and forth on this issue. The problem is that we
> > > have a common case of ns16550 like devices that require a little bit
> > > of register address tweaking that spans a whole range of vendors (so
> > > adding a compatible match with each of those vendor's prefixes is
> > > probably non-scalable). So, if "ns16550" is not a good idea, then
> > > what should be used? "sparse16550" has been suggested more than once.
> >
> > After another IRC discussion between Grant, Segher and myself, we concluded
> > that we don't need to invent a new "compatible" value, as only new device
> > trees with old kernels will have a problem with this, and they don't work
> > in the first place.
> >
> > The devices will still have their specific "compatible" value, e.g.
> > "xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
> > "ns16450" and "i8250", although the last two do not have an effect
> > on Linux.
> >
> > Josh, can you please forward all three patches in their latest version?
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> So is the discussion on reg-offset settled then? It seemed Paul and
> David had some issues with that, and I'd like to make sure everyone is
> agreed on that before I bring in patches 2 and 3.
I didn't like it very much, but I don't really care enough to argue
about it.
--
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] Add idle wait support for 44x platforms
From: Josh Boyer @ 2008-04-08 2:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <200804080441.28739.arnd@arndb.de>
On Tue, 8 Apr 2008 04:41:28 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 08 April 2008, Josh Boyer wrote:
> > >=20
> > > Actually, a static assignment to 0 has not caused the symbol to end up
> > > in .data for many gcc versions, it always goes into .bss now unless y=
ou
> > > assign it a value other than 0 or use explicit section attributes.
> >=20
> > IIRC, gcc 3.2 is still supported and it didn't do that. =C2=A0Old toolc=
hains
> > still exist.
>=20
> Ok, I thought it was before 3.2. The oldest version I had around was
> gcc-3.3 and that had the new behaviour.
http://www.gnu.org/software/gcc/gcc-3.3/changes.html
gcc 3.3.1 it seems. I thought I included that in the original reply,
but it's late and I suck :).
josh
^ permalink raw reply
* Re: [PATCH 3 of 3] [KVM POWERPC] PowerPC 440 KVM implementation
From: Arnd Bergmann @ 2008-04-08 2:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-devel, kvm-ppc-devel, Hollis Blanchard
In-Reply-To: <b07f3049f16483f80322.1207601614@localhost.localdomain>
On Monday 07 April 2008, Hollis Blanchard wrote:
> --- a/include/asm-powerpc/kvm.h
> +++ b/include/asm-powerpc/kvm.h
> @@ -1,6 +1,55 @@
> +/*
> + * 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. =A0See 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, 51 Franklin Street, Fifth Floor, Boston, MA =A002110-1301=
, USA.
> + *
> + * Copyright IBM Corp. 2007
> + *
> + * Authors: Hollis Blanchard <hollisb@us.ibm.com>
> + */
> +
> =A0#ifndef __LINUX_KVM_POWERPC_H
> =A0#define __LINUX_KVM_POWERPC_H
> =A0
> -/* powerpc does not support KVM */
> +#include <asm/types.h>
> =A0
> -#endif
> +struct kvm_regs {
> +=A0=A0=A0=A0=A0=A0=A0__u32 pc;
> +=A0=A0=A0=A0=A0=A0=A0__u32 cr;
> +=A0=A0=A0=A0=A0=A0=A0__u32 ctr;
> +=A0=A0=A0=A0=A0=A0=A0__u32 lr;
> +=A0=A0=A0=A0=A0=A0=A0__u32 xer;
> +=A0=A0=A0=A0=A0=A0=A0__u32 msr;
> +=A0=A0=A0=A0=A0=A0=A0__u32 srr0;
> +=A0=A0=A0=A0=A0=A0=A0__u32 srr1;
> +=A0=A0=A0=A0=A0=A0=A0__u32 pid;
> +
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg0;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg1;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg2;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg3;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg4;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg5;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg6;
> +=A0=A0=A0=A0=A0=A0=A0__u32 sprg7;
> +
> +=A0=A0=A0=A0=A0=A0=A0__u64 fpr[32];
> +=A0=A0=A0=A0=A0=A0=A0__u32 gpr[32];
> +};
> +
> +struct kvm_sregs {
> +};
> +
> +struct kvm_fpu {
> +};
> +
> +#endif /* __LINUX_KVM_POWERPC_H */
Since this defines part of the ABI, it would be nice if it's possible
to have it in a platform independent way. Most of the registers here
should probably become "unsigned long" instead of "__u32" so that
the definition can be used for a potential 64 bit port.
Also, I noticed that you lump everything into kvm_regs, instead of
using sregs for stuff like srr0 and kvm_fpu for the fprs. What is
the reason for that?
Arnd <><
^ permalink raw reply
* Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
From: Hollis Blanchard @ 2008-04-08 3:25 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <20080408011128.GA13454@localhost.localdomain>
On Monday 07 April 2008 20:11:28 David Gibson wrote:
> On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > 1 file changed, 7 insertions(+)
> > include/linux/kvm.h | 7 +++++++
> >
> >
> > Device Control Registers are essentially another address space found on
> > PowerPC 4xx processors, analogous to PIO on x86. DCRs are always 32 bits,
> > and are identified by a 32-bit number.
>
> Well... 10-bit, actually.
The mtdcrux description in the ppc440x6 user manual says the following:
Let the contents of register RA denote a Device Control Register.
The contents of GPR[RS] are placed into the designated Device Control
Register.
I take that to mean that we must worry about 32 bits worth of DCR numbers.
Perhaps I should say "no more than" rather than "always".
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: Booting a Xilinx board
From: Grant Likely @ 2008-04-08 3:55 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <10a101c898c4$c183ee40$f52f9e86@LPSC0173W>
On Mon, Apr 7, 2008 at 9:33 AM, Guillaume Dargaud <dargaud@lpsc.in2p3.fr> wrote:
>
> Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/sysace/disc0/part2 rw
> Uncompressing Linux...done.
> Now booting the kernel
>
> And then it stops.
> I'm sure I've overlooked something obvious...
Are you using uartlite? Try console=ttyUL0.
But Stephen is right, the first thing you should do is look at
__log_buf. You can find its address in the System.map file.
Cheers,
g.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
From: David Gibson @ 2008-04-08 3:54 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <200804072225.33040.hollisb@us.ibm.com>
On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > 1 file changed, 7 insertions(+)
> > > include/linux/kvm.h | 7 +++++++
> > >
> > >
> > > Device Control Registers are essentially another address space found on
> > > PowerPC 4xx processors, analogous to PIO on x86. DCRs are always 32 bits,
> > > and are identified by a 32-bit number.
> >
> > Well... 10-bit, actually.
>
> The mtdcrux description in the ppc440x6 user manual says the following:
>
> Let the contents of register RA denote a Device Control Register.
> The contents of GPR[RS] are placed into the designated Device Control
> Register.
>
> I take that to mean that we must worry about 32 bits worth of DCR numbers.
> Perhaps I should say "no more than" rather than "always".
I think that's less misleading. mtdcrux is very new, anything which
only has the mtdcr instruction certainly can't take DCR numbers above
10 bits, and I would expect that even on chips with mtdcrux the DCR
bus is probably still only 10-bits, although it could be extended.
--
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 of 3] [KVM POWERPC] PowerPC 440 KVM implementation
From: Hollis Blanchard @ 2008-04-08 4:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <20080407211240.4fc5c6d9@zod.rchland.ibm.com>
On Monday 07 April 2008 21:12:40 Josh Boyer wrote:
> On Mon, 07 Apr 2008 15:53:34 -0500
>
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
> > Currently supports only PowerPC 440 Linux guests on 440 hosts. (Only
> > tested with 440EP "Bamboo" guests so far, but with appropriate userspace
> > support other SoC/board combinations should work.)
>
> I haven't reviewed the whole patch yet, but lots of it looks pretty
> clean. A couple comments on some things that made me scratch my head
> below.
>
> > Interrupt handling: We use IVPR to hijack the host interrupt vectors
> > while running the guest, but hand off decrementer and external interrupts
> > for normal guest processing.
> >
> > Address spaces: We take advantage of the fact that Linux doesn't use the
> > AS=1 address space (in host or guest), which gives us virtual address
> > space to use for guest mappings. While the guest is running, the host
> > kernel remains mapped in AS=0, but the guest can only use AS=1 mappings.
> >
> > TLB entries: The TLB entries covering the host linear address space
> > remain present while running the guest (which reduces the overhead of
> > lightweight exits). We keep three copies of the TLB:
> > - guest TLB: contents of the TLB as the guest sees it
> > - shadow TLB: the TLB that is actually in hardware while guest is
> > running - host TLB: to restore TLB state when context switching guest ->
> > host When a TLB miss occurs because a mapping was not present in the
> > shadow TLB, but was present in the guest TLB, KVM handles the fault
> > without invoking the guest. Large guest pages are backed by multiple 4KB
> > shadow pages through this mechanism.
> >
> > Instruction emulation: The guest kernel executes at user level, so
> > executing privileged instructions trap into KVM, where we decode and
> > emulate them. Future performance work will focus on reducing the overhead
> > and frequency of these traps.
> >
> > IO: MMIO and DCR accesses are emulated by userspace. We use virtio for
> > network and block IO, so those drivers must be enabled in the guest. It's
> > possible that some qemu device emulation (e.g. e1000 or rtl8139) may also
> > work with little effort.
> >
> > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
>
> As Olof pointed out, having this in Documentation might be nice.
Yeah, the trouble is that a book could be written on the subject. (OK, a short
book. At least a paper.) Anyways, I will provide something...
> > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> > --- a/arch/powerpc/Kconfig.debug
> > +++ b/arch/powerpc/Kconfig.debug
> > @@ -151,6 +151,7 @@
> >
> > config PPC_EARLY_DEBUG
> > bool "Early debugging (dangerous)"
> > + depends on !KVM
> > help
> > Say Y to enable some early debugging facilities that may be available
> > for your processor/board combination. Those facilities are hacks
>
> Might want to add a brief explanation as to why this doesn't work with
> KVM due to the AS conflict.
Will do.
> > diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/kvm/44x_tlb.c
> > @@ -0,0 +1,224 @@
> > +/*
> > + * 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, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
> > USA. + *
> > + * Copyright IBM Corp. 2007
> > + *
> > + * Authors: Hollis Blanchard <hollisb@us.ibm.com>
> > + */
> > +
> > +#include <linux/types.h>
> > +#include <linux/string.h>
> > +#include <linux/kvm_host.h>
> > +#include <linux/highmem.h>
> > +#include <asm/mmu-44x.h>
> > +#include <asm/kvm_ppc.h>
> > +
> > +#include "44x_tlb.h"
> > +
> > +#define PPC44x_TLB_USER_PERM_MASK
> > (PPC44x_TLB_UX|PPC44x_TLB_UR|PPC44x_TLB_UW) +#define
> > PPC44x_TLB_SUPER_PERM_MASK (PPC44x_TLB_SX|PPC44x_TLB_SR|PPC44x_TLB_SW) +
> > +static unsigned int kvmppc_tlb_44x_pos;
> > +
> > +static u32 kvmppc_44x_tlb_shadow_attrib(u32 attrib, int usermode)
> > +{
> > + /* XXX remove mask when Linux is fixed */
> > + attrib &= 0xf03f;
>
> What does that mean? Is this the "44x TLB handler writes to reserved
> fields" issue? If so, could you comment that a little more verbosely?
Yup, you're right. Actually, what I should really do is this:
attrib &= PPC44x_TLB_ATTR_MASK | PPC44x_TLB_PERM_MASK;
> Or you could just send a patch to fix Linux... ;).
I had a look at it once, but didn't have time to grok the assembly bit
manipulations. I guess nobody else has either. :)
> > +
> > + if (!usermode) {
> > + /* Guest is in supervisor mode, so we need to translate guest
> > + * supervisor permissions into user permissions. */
> > + attrib &= ~PPC44x_TLB_USER_PERM_MASK;
> > + attrib |= (attrib & PPC44x_TLB_SUPER_PERM_MASK) << 3;
> > + }
> > +
> > + /* Make sure host can always access this memory. */
> > + attrib |= PPC44x_TLB_SX|PPC44x_TLB_SR|PPC44x_TLB_SW;
> > +
> > + return attrib;
> > +}
> > +
>
> <snip>
>
> > diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/kvm/emulate.c
> > @@ -0,0 +1,753 @@
> > +/*
> > + * 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, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
> > USA. + *
> > + * Copyright IBM Corp. 2007
> > + *
> > + * Authors: Hollis Blanchard <hollisb@us.ibm.com>
> > + */
> > +
> > +#include <linux/jiffies.h>
> > +#include <linux/timer.h>
> > +#include <linux/types.h>
> > +#include <linux/string.h>
> > +#include <linux/kvm_host.h>
> > +
> > +#include <asm/dcr.h>
> > +#include <asm/time.h>
> > +#include <asm/byteorder.h>
> > +#include <asm/kvm_ppc.h>
>
> #include <asm/dcr-regs.h>
>
> > +
> > +#include "44x_tlb.h"
> > +
> > +#define DCRN_CPR0_CFGADDR 0xc
> > +#define DCRN_CPR0_CFGDATA 0xd
>
> Remove these.
OK.
> <snip>
>
> > +int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu
> > *vcpu) +{
> > + u32 inst = vcpu->arch.last_inst;
> > + u32 ea;
> > + int ra;
> > + int rb;
> > + int rc;
> > + int rs;
> > + int rt;
> > + int sprn;
> > + int dcrn;
> > + enum emulation_result emulated = EMULATE_DONE;
> > + int advance = 1;
> > +
> > + switch (get_op(inst)) {
>
> <snip>
>
> > + case 323: /* mfdcr */
> > + dcrn = get_dcrn(inst);
> > + rt = get_rt(inst);
> > +
> > + /* emulate some access in kernel */
> > + switch (dcrn) {
> > + case DCRN_CPR0_CFGADDR:
> > + vcpu->arch.gpr[rt] = vcpu->arch.cpr0_cfgaddr;
> > + break;
> > + case DCRN_CPR0_CFGDATA:
> > + local_irq_disable();
> > + mtdcr(DCRN_CPR0_CFGADDR,
> > + vcpu->arch.cpr0_cfgaddr);
> > + vcpu->arch.gpr[rt] = mfdcr(DCRN_CPR0_CFGDATA);
> > + local_irq_enable();
> > + break;
> > + default:
> > + run->dcr.dcrn = dcrn;
> > + run->dcr.data = 0;
> > + run->dcr.is_write = 0;
> > + vcpu->arch.io_gpr = rt;
> > + vcpu->arch.dcr_needed = 1;
> > + emulated = EMULATE_DO_DCR;
> > + }
> > +
> > + break;
>
> <snip>
>
> > + case 451: /* mtdcr */
> > + dcrn = get_dcrn(inst);
> > + rs = get_rs(inst);
> > +
> > + /* emulate some access in kernel */
> > + switch (dcrn) {
> > + case DCRN_CPR0_CFGADDR:
> > + vcpu->arch.cpr0_cfgaddr = vcpu->arch.gpr[rs];
> > + break;
> > + default:
> > + run->dcr.dcrn = dcrn;
> > + run->dcr.data = vcpu->arch.gpr[rs];
> > + run->dcr.is_write = 1;
> > + vcpu->arch.dcr_needed = 1;
> > + emulated = EMULATE_DO_DCR;
> > + }
> > +
> > + break;
>
> What exactly are those doing? I'm confused as to why the CPR0 DCRs are
> special cased. Also, you don't seem to actually be doing much on
> storing guest DCRs, so can I assume they aren't really needed at
> runtime?
A 440 cuImage accesses CPR0 DCRs to determine the timebase frequency.
Ordinarily, these DCR accesses would be handed to userspace (qemu) to
emulate.
To emulate this in userspace, we could extract the TB freq from the
host's /proc/device-tree (userspace can't directly access DCRs), but honestly
I didn't want to deal with the math necessary to decompose that back into the
various CPR0 register fields. So instead I special-case CPR0 reads in the
kernel.
The guest needs to know the real/host timebase frequency anyways, since it can
execute mftb without host involvement, and will get very confused if the
timebase increments at a different frequency than it expects.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
From: Hollis Blanchard @ 2008-04-08 4:06 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <20080408035441.GA18501@localhost.localdomain>
On Monday 07 April 2008 22:54:41 David Gibson wrote:
> On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> > On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > > 1 file changed, 7 insertions(+)
> > > > include/linux/kvm.h | 7 +++++++
> > > >
> > > >
> > > > Device Control Registers are essentially another address space found
> > > > on PowerPC 4xx processors, analogous to PIO on x86. DCRs are always
> > > > 32 bits, and are identified by a 32-bit number.
> > >
> > > Well... 10-bit, actually.
> >
> > The mtdcrux description in the ppc440x6 user manual says the following:
> >
> > Let the contents of register RA denote a Device Control Register.
> > The contents of GPR[RS] are placed into the designated Device Control
> > Register.
> >
> > I take that to mean that we must worry about 32 bits worth of DCR
> > numbers. Perhaps I should say "no more than" rather than "always".
>
> I think that's less misleading. mtdcrux is very new, anything which
> only has the mtdcr instruction certainly can't take DCR numbers above
> 10 bits, and I would expect that even on chips with mtdcrux the DCR
> bus is probably still only 10-bits, although it could be extended.
We're defining a kernel/userspace interface here, and since the hardware is
capable of 32-bit DCR numbers, I don't think it makes any sense to not
support that. Also, we would just end up placing that number into a u32
anyways, so... :)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 2 of 3] [KVM] Add DCR access information to struct kvm_run
From: David Gibson @ 2008-04-08 4:16 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <200804072306.10684.hollisb@us.ibm.com>
On Mon, Apr 07, 2008 at 11:06:10PM -0500, Hollis Blanchard wrote:
> On Monday 07 April 2008 22:54:41 David Gibson wrote:
> > On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> > > On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > > > 1 file changed, 7 insertions(+)
> > > > > include/linux/kvm.h | 7 +++++++
> > > > >
> > > > >
> > > > > Device Control Registers are essentially another address space found
> > > > > on PowerPC 4xx processors, analogous to PIO on x86. DCRs are always
> > > > > 32 bits, and are identified by a 32-bit number.
> > > >
> > > > Well... 10-bit, actually.
> > >
> > > The mtdcrux description in the ppc440x6 user manual says the following:
> > >
> > > Let the contents of register RA denote a Device Control Register.
> > > The contents of GPR[RS] are placed into the designated Device Control
> > > Register.
> > >
> > > I take that to mean that we must worry about 32 bits worth of DCR
> > > numbers. Perhaps I should say "no more than" rather than "always".
> >
> > I think that's less misleading. mtdcrux is very new, anything which
> > only has the mtdcr instruction certainly can't take DCR numbers above
> > 10 bits, and I would expect that even on chips with mtdcrux the DCR
> > bus is probably still only 10-bits, although it could be extended.
>
> We're defining a kernel/userspace interface here, and since the hardware is
> capable of 32-bit DCR numbers, I don't think it makes any sense to not
> support that. Also, we would just end up placing that number into a u32
> anyways, so... :)
Oh, of course you should represent it as a u32 and support 32-bit
addresses, it's only the patch comment I'm objecting to.
--
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 of 3] [KVM POWERPC] PowerPC 440 KVM implementation
From: Hollis Blanchard @ 2008-04-08 4:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: kvm-devel, linuxppc-dev, kvm-ppc-devel
In-Reply-To: <200804080458.17783.arnd@arndb.de>
On Monday 07 April 2008 21:58:17 Arnd Bergmann wrote:
> On Monday 07 April 2008, Hollis Blanchard wrote:
> > --- a/include/asm-powerpc/kvm.h
> > +++ b/include/asm-powerpc/kvm.h
> > @@ -1,6 +1,55 @@
> > +/*
> > + * 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. =A0See 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, 51 Franklin Street, Fifth Floor, Boston, MA =A002110-13=
01,
> > USA. + *
> > + * Copyright IBM Corp. 2007
> > + *
> > + * Authors: Hollis Blanchard <hollisb@us.ibm.com>
> > + */
> > +
> > =A0#ifndef __LINUX_KVM_POWERPC_H
> > =A0#define __LINUX_KVM_POWERPC_H
> > =A0
> > -/* powerpc does not support KVM */
> > +#include <asm/types.h>
> > =A0
> > -#endif
> > +struct kvm_regs {
> > +=A0=A0=A0=A0=A0=A0=A0__u32 pc;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 cr;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 ctr;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 lr;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 xer;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 msr;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 srr0;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 srr1;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 pid;
> > +
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg0;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg1;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg2;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg3;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg4;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg5;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg6;
> > +=A0=A0=A0=A0=A0=A0=A0__u32 sprg7;
> > +
> > +=A0=A0=A0=A0=A0=A0=A0__u64 fpr[32];
> > +=A0=A0=A0=A0=A0=A0=A0__u32 gpr[32];
> > +};
> > +
> > +struct kvm_sregs {
> > +};
> > +
> > +struct kvm_fpu {
> > +};
> > +
> > +#endif /* __LINUX_KVM_POWERPC_H */
>
> Since this defines part of the ABI, it would be nice if it's possible
> to have it in a platform independent way. Most of the registers here
> should probably become "unsigned long" instead of "__u32" so that
> the definition can be used for a potential 64 bit port.
If there is one thing I have learned in my various porting efforts, it's th=
at=20
using a variable-sized type in an interface is just begging for trouble.
x86 uses fixed 64-bit variables here (even with x86-32), so that might be t=
he=20
right solution here.
> Also, I noticed that you lump everything into kvm_regs, instead of
> using sregs for stuff like srr0 and kvm_fpu for the fprs. What is
> the reason for that?
The FPRs and SPRs are only really useful for two things here: debugger supp=
ort=20
and migration. We don't really support either at the moment, so this part o=
f=20
the user/kernel ABI will need change as we implement those.
I will move the FPR stuff into kvm_fpu though. (I think when I originally=20
wrote this, kvm_fpu was defined to be x86 stuff, but it obviously isn't=20
now...)
=2D-=20
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] PowerPC 44x: use machine_device_initcall() instead ofdevice_initcall() for warp_nand
From: Sean MacLennan @ 2008-04-08 4:21 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080404182437.GA18185@ru.mvista.com>
On Fri, 4 Apr 2008 22:24:37 +0400
"Valentine Barshak" <vbarshak@ru.mvista.com> wrote:
> With a multiplatform kernel, once built we always have
> warp_setup_nand_flash() called and NDFC probed, no matter what
> machine we actually run on. This potentially can cause problems (such
> as kernel crash), since NDFC is probed at a warp-predefined address.
> Using machine_device_initcall() NAND devices are registered if we run
> on a warp only.
Thanks for catching that. I have gotten *way* behind on my email and am
only reading this now.
Cheers,
Sean
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH 3 of 3] [KVM POWERPC] PowerPC 440 KVM implementation
From: Arnd Bergmann @ 2008-04-08 5:09 UTC (permalink / raw)
To: kvm-ppc-devel; +Cc: kvm-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <200804072319.11677.hollisb@us.ibm.com>
On Tuesday 08 April 2008, Hollis Blanchard wrote:
> If there is one thing I have learned in my various porting efforts, it's that
> using a variable-sized type in an interface is just begging for trouble.
>
> x86 uses fixed 64-bit variables here (even with x86-32), so that might be the
> right solution here.
Right, I think there was even a conference presentation about this topic
done by one of us, right?
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/9 v2] powerpc: change FDT compatible prefix to mrvl
From: Segher Boessenkool @ 2008-04-08 6:34 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20080407210314.GA21993@farnsworth.org>
>> Either use the stock ticker, in UPPER CASE, or use a nice
>> descriptive name. The lower case space is "free for all",
>> using shortened names (like "mrvl") there only increases
>> the chances of collisions.
>
> Frankly Segher, it doesn't matter to me. However, NONE of the
> existing DTS files use upper-case stock ticker. I see no reason
> to deviate from the existing convention
It's not an existing convention, it's a mistake some people made ;-)
> (even if that convention
> doesn't follow the previously defined upper-case stock ticker
> convention.)
That's not a "previously defined convention", it's the defined
rules in the OF standard. Conventions are examples that are nice
to follow if there's no real reason to choose either way; standards
are things that if you break them, people shout out you.
Let me say this again: it is *fine* if you use some lower-case name.
In that case though, "marvell" is slightly better than "mrvl", and
you had the former already, so just keep it :-)
Agreed? Ca we move on now? :-)
Segher
^ permalink raw reply
* Re: Kilauea: kernel hangs when using ARCH=powerpc
From: Bernhard Weirich @ 2008-04-08 7:36 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1207574594.6809.23.camel@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 164 bytes --]
> You need to be sure to load the device tree blob in U-Boot, ...
>
> josh
>
Thank you very much. This was just the missing piece of info I needed.
Bernhard
[-- Attachment #2: Type: text/html, Size: 507 bytes --]
^ permalink raw reply
* Re: Question on mpc52xx_common.c
From: Sven Luther @ 2008-04-08 7:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Detlev Zundel, sven
In-Reply-To: <200804080414.42867.arnd@arndb.de>
On Tue, Apr 08, 2008 at 04:14:42AM +0200, Arnd Bergmann 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?
for 2.6.24, device-tree fixups where added to the linux kernel, since we
don't have a possibility to modify the efika dt, or at least not in a
foreseable future, we should just add more fixups so we can handle
various other problems in it.
Friendly,
Sven Luther
^ 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 8:21 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: kernel list, linuxppc-dev, linux-next, Andrew Morton,
Balbir Singh
In-Reply-To: <47BC40BC.3040405@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> The Kernel oopses is seen while running the kernbench followed by tbench with 2.6.25-rc2-git4
> kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel (http://lkml.org/lkml/2008/1/18/71)
> and is visible with almost all of the main line ,rc(s) and their git(s) release from then.
>
> This oops is visible in the linux-next-20080220 kernel also.The machine is power4+ box with four cpus and
> has 30 GB RAM.
Please try to replicate the oops with the patch below applied. It
doesn't solve the cause of the oops but it should mean the kernel
prints out more useful information about the cause of the oops.
I assume you can replicate the oops easily on this machine - is that
right?
Paul.
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 11b4f6d..a3ac72a 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -621,7 +621,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
mtlr r10
andi. r10,r12,MSR_RI /* check for unrecoverable exception */
- beq- unrecov_slb
+ beq- 2f
.machine push
.machine "power4"
@@ -643,6 +643,22 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
rfid
b . /* prevent speculative execution */
+2:
+#ifdef CONFIG_PPC_ISERIES
+BEGIN_FW_FTR_SECTION
+ b unrecov_slb
+END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
+#endif /* CONFIG_PPC_ISERIES */
+ mfspr r11,SPRN_SRR0
+ clrrdi r10,r13,32
+ LOAD_HANDLER(r10,unrecov_slb)
+ mtspr SPRN_SRR0,r10
+ mfmsr r10
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI
+ mtspr SPRN_SRR1,r10
+ rfid
+ b .
+
unrecov_slb:
EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB)
DISABLE_INTS
^ permalink raw reply related
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Andre Schwarz @ 2008-04-08 8:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080407161036.GA2688@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 5222 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
>
Scott,
thanks for your reply.
please find below the output after the bootm command in u-boot.
My System.map :
...
c00126b8 T strcpy
c00126d4 T strncpy
c0012714 T strcat
c0012740 T strcmp
c0012764 T strlen
c001277c T memcmp
...
c0140bc4 T of_find_property
c0140c74 T of_get_property
c0140ca8 T of_device_is_compatible
c0140d48 T of_match_node
c0140e68 T of_find_matching_node
c0140f20 T of_n_size_cells
c0140f9c T of_n_addr_cells
Log:
# Booting kernel from Legacy Image at ff810000 ...
Image Name: 2.6.25 mvBL-M7 MPC8343 #1
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 2084636 Bytes = 2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
## Flattened Device Tree blob at 00000000
Booting using the fdt blob at 0x600000
## Loading init Ramdisk from Legacy Image at 01000000 ...
Image Name: mvBC-1G uInitrd #1.1.03
Image Type: PowerPC Linux RAMDisk Image (uncompressed)
Data Size: 2654208 Bytes = 2.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 1fcb7000, end 1ff3f000 ... OK
-> early_init_devtree(c0600000)
search "chosen", depth: 0, uname:
search "chosen", depth: 1, uname: chosen
Looking for initrd properties... <3>initrd_start=0xdfcb7000
initrd_end=0xdff3f000
Command line is: root=/dev/ram ro rootfstype=squashfs
dt_root_size_cells = 1
dt_root_addr_cells = 1
memory scan node memory, reg size 8, data: 0 20000000 2 1,
- 0 , 20000000
reserving: 1fcb7000 -> 288001
Phys. mem: 20000000
-> move_device_tree
<- move_device_tree
Scanning CPUs ...
boot cpu: logical 0 physical 0
<- early_init_devtree()
Using mvBlueLYNX-M7 machine description
Linux version 2.6.25-rc8-01197-g1de15bb-dirty (root@nova) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #1 PREEMPT Tue Apr 8 10:40:51 CEST 2008
-> unflatten_device_tree()
size is 1840, allocating...
unflattening dfffe7bc...
fixed up name for ->
fixed up name for chosen -> chosen
fixed up name for aliases -> aliases
fixed up name for cpus -> cpus
fixed up name for PowerPC,8343@0 -> PowerPC,8343
fixed up name for memory -> memory
fixed up name for soc8343@e0000000 -> soc8343
fixed up name for wdt@200 -> wdt
fixed up name for i2c@3000 -> i2c
fixed up name for rtc@68 -> rtc
fixed up name for i2c@3100 -> i2c
fixed up name for spi@7000 -> spi
fixed up name for usb@22000 -> usb
fixed up name for mdio@24520 -> mdio
fixed up name for ethernet-phy@0 -> ethernet-phy
fixed up name for ethernet-phy@1 -> ethernet-phy
fixed up name for ethernet@24000 -> ethernet
fixed up name for ethernet@25000 -> ethernet
fixed up name for serial@4500 -> serial
fixed up name for serial@4600 -> serial
fixed up name for pic@700 -> pic
fixed up name for localbus@e0005000 -> localbus
fixed up name for flash@0,0 -> flash
<- unflatten_device_tree()
Found initrd at 0xdfcb7000:0xdff3f000
console [udbg0] enabled
setup_arch: bootmem
mvblm7_setup_arch()
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0012748
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT mvBlueLYNX-M7
Modules linked in:
NIP: c0012748 LR: c0140c10 CTR: 00000000
REGS: c01f9e40 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty)
MSR: 00001032 <ME,IR,DR> CR: 22008048 XER: 20000000
DAR: 00000000, DSISR: 20000000
TASK = c01e4510[0] 'swapper' THREAD: c01f8000
GPR00: c0140c84 c01f9ef0 c01e4510 00000000 c0197a7f ffffffff c01f9edc
00000000
GPR08: c01f15e4 00000003 c0600b84 0000004d 22002048 ffffffdf 1fffd000
00000000
GPR16: ffffffdf ffff7fdf 00000000 00000000 1fff8974 1ff426f8 00000004
00288000
GPR24: 00000002 00000000 5f0fffff c01993e4 c01f9f28 c0197a80 c01f8000
dffff9e4
Call Trace:
[c01f9ef0] [c001c190] (unreliable)
[c01f9f10] [c0140c84]
[c01f9f20] [c0140ccc]
[c01f9f40] [c014145c]
[c01f9f60] [c0014014]
[c01f9fa0] [c01d1a40]
[c01f9fb0] [c01ce64c]
[c01f9fc0] [c01c55ac]
[c01f9ff0] [00003438]
Instruction dump:
3884ffff 8c050001 2c000000 4082fff8 38a5ffff 8c040001 2c000000 9c050001
4082fff4 4e800020 38a3ffff 3884ffff <8c650001> 2c830000 8c040001 7c601851
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
Please let me know if you need more information.
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: 6442 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Laurent Pinchart @ 2008-04-08 9:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080311172429.GF7727@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts.
>
> There are several limitations in this support:
> 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
> This is straightforward to implement when needed, two timers should
> be marked as "requested" and configured as appropriate.
> 2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
> This is also straightforward to implement when needed, all timers
> should be marked as "requested" and configured as appropriate.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
[snip]
> +void gtm_stop_timer_16(struct gtm_timer *tmr)
> +{
> + struct gtm *gtm = tmr->gtm;
> + int num = tmr - >m->timers[0];
> + unsigned long flags;
> +
> + spin_lock_irqsave(>m->lock, flags);
> +
> + setbits8(tmr->gtcfr, GTCFR_STP(num));
Shouldn't we clear the timer events with
out_be16(tmr->gtevr, 0xFFFF);
here ? Otherwise the timer interrupt could still fire after the timer is
stopped. This introduces a race condition in drivers that blindly re-arm the
timer in the interrupt handler. I've been bitten by this while porting your
FHCI USB driver to a CPM2 platform.
> +
> + spin_unlock_irqrestore(>m->lock, flags);
> +}
> +EXPORT_SYMBOL(gtm_stop_timer_16);
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Booting a Xilinx board
From: Guillaume Dargaud @ 2008-04-08 9:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40804072055i1f7036afn4d453e968cc625d6@mail.gmail.com>
> Are you using uartlite? Try console=ttyUL0.
Thanks, I didn't know that.
> But Stephen is right, the first thing you should do is look at
> __log_buf. You can find its address in the System.map file.
Unfortunately, the installation of the cable driver failed for some reason.
I'll have to work on it...
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: MVL Linux on MPC8560 Booting goes into infinite loop inearly_init memset_io ( )
From: Deepak Gaur @ 2008-04-08 11:15 UTC (permalink / raw)
To: David Baird, linuxppc-embedded
In-Reply-To: <440abda90804071250v60bd970fh938e9690836ab61@mail.gmail.com>
Hi,
Thanks for valuable inputs.. memset_io() issue got resolved after I invalidated the L1
data and Instruction cache before calling early_init(was mentioned in some mailing list
). The code execution resumed and somewhere during MMU_init it again got struck.This
time its due to a DataTLBError. I am now trying to trace the function causing TLB miss
using ICE Trace32. Any pointers for reason behind generation of DataTLBError during MMU_init
Thanks
Deepak Gaur
On Mon, 7 Apr 2008 13:50:04 -0600, David Baird wrote
> On Mon, Apr 7, 2008 at 10:04 AM, Scott Wood <scottwood@freescale.com> wrote:
> > BTW, it's generally bad form to post the same question repeatedly. If you
> > have new information regarding your problem, just post a followup in the
> > same thread containing the new information.
>
> Agreed! I was about to respond to your new post, and then I
> discovered this nearly identical slightly older post.
>
> On Mon, Apr 7, 2008 at 12:37 AM, Deepak Gaur <gaur.deepak@gmail.com> wrote:
> > While booting MVL linux on MPC8560 based board the kernel goes into a
> > infinite loop in setup.c
>
> Someone please correct me if I am wrong, but those symbols inside the
> BSS should only be variables (not functions....) which are initialized
> to zero. The whole reason for BSS is to initialize variables to a
> 0/null value.
>
> Now, about the infinite loop. Can you check to see if perhaps you are
> getting an exception?
>
> I have no experience with the MPC8560, but I've seen a couple problems
> that occur involving memset_io. What happens is that a TLB miss
> exception occurs when the CPU gets inside of memset_io. Do you have
> the ability to check that with a debugger (by setting breakpoints at
> exceptions, such as the data and instruction TLB miss exceptions) to
> see if you are getting exceptions?
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Deepak Gaur
^ permalink raw reply
* [Fwd: Re: MPC8343 - "unable to handle paging request @ 0"]
From: Andre Schwarz @ 2008-04-08 11:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ppc list
[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]
sorry - forgot Kim + List
-------- Original-Nachricht --------
Betreff: Re: MPC8343 - "unable to handle paging request @ 0"
Datum: Tue, 08 Apr 2008 13:29:20 +0200
Von: Andre Schwarz <andre.schwarz@matrix-vision.de>
An: Scott Wood <scottwood@freescale.com>
Referenzen: <47F73625.9040903@matrix-vision.de>
<20080407161036.GA2688@loki.buserror.net>
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
>
Scott,
after removing "mpc834x_usb_cfg()" from my "mvblm7_setup_arch()" the
crash is delayed ...
regards,
Andre
System-map :
c0012098 T strcpy
c00120b4 T strncpy
c00120f4 T strcat
c0012120 T strcmp
c0012144 T strlen
...
c00ecd08 T of_find_property
c00ecda4 T of_get_property
c00ecdd8 T of_n_size_cells
console [udbg0] enabled
setup_arch: bootmem
mvblm7_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: root=/dev/ram ro rootfstype=squashfs
PID hash table entries: 2048 (order: 11, 8192 bytes)
clocksource: timebase mult[3c00001] shift[22] registered
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0012128
Oops: Kernel access of bad area, sig: 11 [#1]
mvBlueLYNX-M7
Modules linked in:
NIP: c0012128 LR: c00ecd44 CTR: 00000007
REGS: c0193ec0 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 48002048 XER: 00000000
DAR: 00000000, DSISR: 20000000
TASK = c0182510[0] 'swapper' THREAD: c0192000
GPR00: c00ecdb4 c0193f70 c0182510 00000000 c01401c7 ffffffff c017a808
c00db350
GPR08: 00000000 c0180000 000a2c20 c017d3f4 48000042 ffffdfd7 1fffd000
00000000
GPR16: ffffdfd7 ffffdfd7 00000000 00000000 1fff8974 1ff426f8 00000004
00288000
GPR24: 00000000 00000000 c0198fa0 c0190000 c0190000 00000000 c01401c8
dfffffa8
Call Trace:
[c0193f70] [00001111] (unreliable)
[c0193f90] [c00ecdb4]
[c0193fa0] [c016df50]
[c0193fb0] [c017705c]
[c0193fc0] [c01646b4]
[c0193ff0] [00003438]
Instruction dump:
3884ffff 8c050001 2c000000 4082fff8 38a5ffff 8c040001 2c000000 9c050001
4082fff4 4e800020 38a3ffff 3884ffff <8c650001> 2c830000 8c040001 7c601851
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
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: 5129 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-04-08 11:48 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804081101.55784.laurentp@cse-semaphore.com>
On Tue, Apr 08, 2008 at 11:01:53AM +0200, Laurent Pinchart wrote:
> On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
> > GTM stands for General-purpose Timers Module and able to generate
> > timer{1,2,3,4} interrupts.
> >
> > There are several limitations in this support:
> > 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
> > This is straightforward to implement when needed, two timers should
> > be marked as "requested" and configured as appropriate.
> > 2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
> > This is also straightforward to implement when needed, all timers
> > should be marked as "requested" and configured as appropriate.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> [snip]
>
> > +void gtm_stop_timer_16(struct gtm_timer *tmr)
> > +{
> > + struct gtm *gtm = tmr->gtm;
> > + int num = tmr - >m->timers[0];
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>m->lock, flags);
> > +
> > + setbits8(tmr->gtcfr, GTCFR_STP(num));
>
> Shouldn't we clear the timer events with
>
> out_be16(tmr->gtevr, 0xFFFF);
Yeah.
> here ? Otherwise the timer interrupt could still fire after the timer is
> stopped. This introduces a race condition in drivers that blindly re-arm the
> timer in the interrupt handler. I've been bitten by this while porting your
> FHCI USB driver to a CPM2 platform.
Thanks, will fix.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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 11:51 UTC (permalink / raw)
To: Paul Mackerras
Cc: kernel list, linuxppc-dev, linux-next, nacc, Andrew Morton,
Balbir Singh
In-Reply-To: <18427.11023.8067.795279@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The Kernel oopses is seen while running the kernbench followed by tbench with 2.6.25-rc2-git4
>> kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel (http://lkml.org/lkml/2008/1/18/71)
>> and is visible with almost all of the main line ,rc(s) and their git(s) release from then.
>>
>> This oops is visible in the linux-next-20080220 kernel also.The machine is power4+ box with four cpus and
>> has 30 GB RAM.
>
> Please try to replicate the oops with the patch below applied. It
> doesn't solve the cause of the oops but it should mean the kernel
> prints out more useful information about the cause of the oops.
>
> I assume you can replicate the oops easily on this machine - is that
> right?
>
> Paul.
>
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 11b4f6d..a3ac72a 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -621,7 +621,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
> mtlr r10
>
> andi. r10,r12,MSR_RI /* check for unrecoverable exception */
> - beq- unrecov_slb
> + beq- 2f
>
> .machine push
> .machine "power4"
> @@ -643,6 +643,22 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
> rfid
> b . /* prevent speculative execution */
>
> +2:
> +#ifdef CONFIG_PPC_ISERIES
> +BEGIN_FW_FTR_SECTION
> + b unrecov_slb
> +END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
> +#endif /* CONFIG_PPC_ISERIES */
> + mfspr r11,SPRN_SRR0
> + clrrdi r10,r13,32
> + LOAD_HANDLER(r10,unrecov_slb)
> + mtspr SPRN_SRR0,r10
> + mfmsr r10
> + ori r10,r10,MSR_IR|MSR_DR|MSR_RI
> + mtspr SPRN_SRR1,r10
> + rfid
> + b .
> +
> unrecov_slb:
> EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB)
> DISABLE_INTS
Hi Paul,
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
please let me know if you need more information.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Anton Vorontsov @ 2008-04-08 12:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Scott Wood, linuxppc-dev, linux-usb, David Brownell, Timur Tabi
In-Reply-To: <200804071811.19671.laurentp@cse-semaphore.com>
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]
> I had a first go at hacking the FHCI driver to make it run on a CPM2 platform.
> Results so far are quite good. After getting rid of qe-specific APIs as
> explained above, and adding SOF token generation support, I've been able to
> access a mass storage device. The driver hasn't been stress-tested yet
> though.
Wow, awesome! That's great news, really. Looking forward for the patch. :-)
> I ran into an issue with IDLE and RESET interrupts. When the device is first
> plugged into the USB port, the idle interrupt kicks in and the driver detects
> the device properly. When the device is then removed, the reset interrupt is
> generated and the driver handles device removal properly. Right after the
> reset interrupt, idle interrupts are generated every milliseconds for around
> 175ms. The status register always reports a non-idle condition when read in
> the interrupt handler. The flow of idle interrupts then stops, and no idle
> interrupt is generated when I replug the device. I've checked the interrupts
> mask register to make sure idle interrupts were enabled.
>
> Have you noticed a similar behaviour when you tested the driver on your
> QE-based platform ? I suspected a debouncing issue, but I should then get
> idle conditions once every other time when reading the status register.
Hm.. nope, I didn't see anything like that, at least not something that
is affecting the driver functionality. Did out_be16(tmr->gtevr, 0xFFFF);
help there? Or it's different problem?
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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