* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: David Gibson @ 2007-09-28 2:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <9c20d018e890250443516b886317ceb9@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote:
> >>> Hrm... we probably want an "i2c" device_type class, but I don't think
> >>> we've actually defined one, which is a problem
> >>
> >> By defining new device_type's, or new semantics for device_type,
> >> you open the door to (accidentally) becoming incompatible with
> >> "real" OF.
> >
> > Hrm... perhaps. But is it a realistic danger - I'll have to think
> > more about that.
>
> It is trivial to avoid these dangers completely by not overloading
> the meaning of "device_type".
Hrm. Perhaps.
> >>> I think we want to think a bit more carefully about how to do
> >>> bindings
> >>> for RTC devices. No "rtc" device_type is defined, but again we might
> >>> want to.
> >>
> >> Actually, "device_type" = "rtc" _is_ defined (in the "device support
> >> extensions" recommended practice), and there is no useful way a flat
> >> device tree can implement it (it merely defines get-time and set-time
> >> methods).
> >
> > Ah.. right. That changes things a bit, in that we might want to
> > include device_type purely for similarity with real OF tree.
>
> You should include the device_type only if you implement its binding,
> and a flat device tree does not, and cannot. (In almost all cases,
> a flat device tree cannot implement device_type's semantics -- this
> means that pretty much the only case where a flat tree should use
> device_type is to have it as a workaround for bad kernel requirements).
I really don't think there's an ambiguity here. A flat-tree can
clearly never implement runtime binding features. This is also true
for a flat tree derived from a real OF, and so full of device_type all
over the place.
> > Real OF has a device_type == "nvram" too, doesn't it?
>
> Yes, same "device support extensions" document.
Erm.. I've lost track amongst our various threads. Which same
document?
> > AFAICT the real
> > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM
> > chips) the RTC is labelled as "nvram" rather than "rtc".
>
> Sounds buggy.
Why?
[snip]
> > I did find one real OF binding for a different Dallas RTC (and NVRAM),
> > see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-
> > it.txt
> >
> > It's a little different from the example above.
>
> That is a binding for the nvram part only, not for the RTC.
Hrm. So how do you suggest we do bindings for combined devices?
--
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 8/15] bootwrapper: convert flatdevtree to version 16
From: David Gibson @ 2007-09-28 2:40 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <41180fced14196db80f261d2ac1909e0@bga.com>
On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
>
> On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
[snip]
> >> What's your souce for saying the were supposed to be backwards
> >> compatable? That dtc fills out the struct header so?
> >
> > Sitting next to BenH and knowing he always intended them to be so.
> >
> >> My source is my involvment when v2 was defined (they were discovered
> >> while writing my device tree generation code):
> >>
> >> The actual binary structure is compatable, just not the contents of
> >> the
> >> properties nor how any slave cpus wait (for some trees it doesn't
> >> matter).
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
> >> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
> >> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
> >
> > An old version of fs2dt is hardly definitive. It could just be Plain
> > Wrong, nothing to do with the dt version.
>
> Sorry, copy and paste error. I was tring to point out this changelog
> in 2.6.10:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
> a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed
Hrm, I see, yes that seems conclusive enough. Yuck.
In which case, I think we should try to forget that v1 ever existed.
I don't think anyone ever generated v1 trees other than kernels which
also consumed them, and I doubt current kernels will correctly deal
with v1 trees in this form.
In any case, this is all rather beside the point. My basic point is
that this bootwrapper stuff should not attempt to be a general
backwards compatibility layer for every broken early dt format that
ever existed. In general we should try to make sure nothing ever uses
<v16 trees. We want, here, to do the minimum we can get away with to
support the specific v2 trees produced by kexec-tools, as an interim
measure while kexec-tools itself is fixed to produce v17 trees (say,
by replacing fs2dt with dtc plus a libfdt based post-processing
program).
--
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 Altivec/VMX state to coredumps
From: Michael Ellerman @ 2007-09-27 23:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <1D8E59FD-E8B1-446C-ABEE-D41F5496B518@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:
> >>> You're probably right :)
> >>>
> >>> What cores have SPE at the moment? Also, perhaps more importantly,
> >>> are there any plans to have Altivec and SPE in the same core?
> >>
> >> The e500 cores's from Freescale.
> >>
> >> No, they are pretty much mutually exclusive.
> >>
> >>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
> >>> the GDB side of this.
> >>
> >> From comments it looks like the expectation is that the combination
> >> of note type and name which is expected to be unique.
> >>
> >> I'm wondering if we should handle this via
> >> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
> >> Does GDB care about the order it sees the various sections in?
> >
> > I don't think those callbacks will work in this case, they're only
> > called for the primary thread that's doing the coredump, not for each
> > thread. Perhaps there's a way to adapt it though.
> >
> > I think the easiest solution for now is just to make the note type a
> > #define and create a new value for Altivec.
>
> Oh, well. It shouldn't be too difficult to abstract vector handler
> similar to how we do GPRs today to the core dump code.
I'm not sure I follow, you mean elf_core_copy_regs() ?
If so, that's basically what we've done, the problem is that as with
elf_core_copy_regs(), although the content is abstracted and overridden
by arch code, the note type is not. But making the vector note type
configurable seems easy enough.
eg:
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..7c8a145 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, struct pt_regs *regs,
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREGS_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 23:34 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927221031.GY3899@parisc-linux.org>
On Thu, Sep 27, 2007 at 04:10:31PM -0600, Matthew Wilcox wrote:
> In the error handler, we wait_for_completion(io_reset_wait).
> In sym2_io_error_detected, we init_completion(io_reset_wait).
> Isn't it possible that we hit the error handler before we hit the
> io_error_detected path, and thus the completion wait is lost?
> Since the completion is already initialised in sym_attach(), I don't
> think we need to initialise it in sym2_io_error_detected().
> Makes sense to just delete it?
Good catch. But no ... and I had to study this a bit. Bear with me:
It is enough to call init_completion() once, and not once per use:
it initializes spinlocks, which shouldn't be intialized twice.
But, that completion might be used multiple times when there are
multiple errors, and so, before using it a second time, one must
set completion->done = 0. The INIT_COMPLETION() macro does this.
One must have completion->done = 0 before every use, as otherwise,
wait_for_completion() won't actually wait. And since complete_all()
sets x->done += UINT_MAX/2, I'm pretty sure x->done won't be zero
the next time we use it, unless we make it so.
So I need to find a place to safely call INIT_COMPLETION() again,
after the completion has been used. At the moment, I'm stumped
as to where to do this.
---- [think ... think ... think] ----
I think the race you describe above is harmless. The first time
that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
in it doesn't matter if we lose that, since the device is hosed
anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
miss those, since, by now, sym2_io_error_detected() will have run.
So, by my reading, I'd say that init_completion() in
sym2_io_error_detected() has to stay (although perhaps
it should be replaced by the INIT_COMPLETION() macro.)
Removing it will prevent correct operation on the second
and subsequent errors.
--Linas
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Paul Mackerras @ 2007-09-27 23:31 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927191233.201980@gmx.net>
Gerhard Pircher writes:
> I'm working on a 2.6.23 kernel for the AmigaOne. I implemented the device
> tree and the platform setup code, which all compiles fine. I built a
> cuImage target, loaded it on my target machine with TFTP and booted it.
> The kernel passes the platform setup code and then dies somewhere in the
> driver init code (AFAICT), but before the keyboard driver is initialized
> (thus magic sysrq key doesn't work). Can somebody help me to track down
> this problem?
You appear to have a working 16550-style serial port which the udbg
infrastructure sees. Thus you should be able to use xmon, talking to
it via the serial port. Put "xmon" on the kernel command line and the
kernel will drop into xmon early in the boot process (in setup_arch).
Then, either the kernel will oops at some point and drop into xmon,
and you can then inspect memory and registers and get a stack trace,
or it will hang at some point. If it hangs, you can work out where it
hangs by putting in breakpoints at various points and seeing which
breakpoints you get to (this might take several boots).
Paul.
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Scott Wood @ 2007-09-27 23:01 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190933846.6601.1.camel@concordia>
Michael Ellerman wrote:
> On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
>> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
>> that leads to a register dump, the kernel currently prints XXXXXXXX because
>> it doesn't realize that PC is a physical address.
>>
>> This patch checks the state of the IMMU, and if necessary converts PC into a
>> virtual address.
>
> IMMU ?
Instruction Memory Management Unit.
-Scott
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Michael Ellerman @ 2007-09-27 22:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Thu, 2007-09-27 at 13:38 -0500, Scott Wood wrote:
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault happens
> that leads to a register dump, the kernel currently prints XXXXXXXX because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC into a
> virtual address.
IMMU ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Detlev Zundel @ 2007-09-27 15:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <12900017.post@talk.nabble.com>
Hi Nethra,
> The other options I am wondering about,
> -c, --cleanmarker=SIZE Size of cleanmarker (default 12)
> -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
> cleanmaker size will it help the cause?
Skimming through the thread I cannot tell whether you use NAND or NOR,
but on NAND flash, the cleanmarkers are actually in the out-of-band
area and thus *should not* be in the image, so for NAND we need the -n
option.
I don't think you should have to adjust the size, at least I never
needed this.
Best wishes
Detlev
--
I've been examining the existing [linux] kernel configuration system, and I
have about concluded that the best favor we could do everybody involved with
it is to take it out behind the barn and shoot it through the head.
-- Eric S. Raymond on linux-kbuild Mar 2000
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Benjamin Herrenschmidt @ 2007-09-27 22:39 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927222733.201970@gmx.net>
On Fri, 2007-09-28 at 00:27 +0200, Gerhard Pircher wrote:
> -------- Original-Nachricht --------
> > Datum: Thu, 27 Sep 2007 17:20:07 -0500
> > Von: linas@austin.ibm.com
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> > On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
> >
> > The last identifiable message I was
> >
> > <7>PCI: Calling quirk...
> >
> > which is from drivers/pci/quirks.c
> >
> > ...CI: Found 0000:00:07.2 [1106/303...
> >
> > and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> > to see if pci_setup_device() ever returned, and then I'd look to see
> > what happened next.
> Ah, I thought probing is done in the architecture's PCI code. I'll take
> a look at pci_setup_device() function.
It's one of the quirks I suppose. Those are often full of x86 only
bogoziness that hurts everybody else if you happen to hit them.
The "late" quirks are called at pci_enable_device() time.
Ben
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:37 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190931617.6158.29.camel@pasglop>
> It should have been set in setup_64.c, in setup_paca() (which is called
> twice) in that statement:
>
> local_paca = &paca[cpu];
>
> As local_paca is defined as being a variable held in register r13. Maybe
> something bad's happening with the compiler ?
Can you check early_setup disassembly, see if r13 is assigned (it should
be in two spots) and if it's clobbered by the compiler somewhere ?
Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
makefile and let us know if it makes a difference... r13 is marked
reserved by the ABI but segher seems to imply that gcc may decide to ues
it anyway (ouch !)
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 22:27 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927222007.GE18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 17:20:07 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> The last identifiable message I was
>
> <7>PCI: Calling quirk...
>
> which is from drivers/pci/quirks.c
>
> ...CI: Found 0000:00:07.2 [1106/303...
>
> and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
> to see if pci_setup_device() ever returned, and then I'd look to see
> what happened next.
Ah, I thought probing is done in the architecture's PCI code. I'll take
a look at pci_setup_device() function.
Thanks!
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:20 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
It should have been set in setup_64.c, in setup_paca() (which is called
twice) in that statement:
local_paca = &paca[cpu];
As local_paca is defined as being a variable held in register r13. Maybe
something bad's happening with the compiler ?
Ben.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 22:20 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927215735.201960@gmx.net>
On Thu, Sep 27, 2007 at 11:57:35PM +0200, Gerhard Pircher wrote:
>
> > Based on your boot messages, it looks like you are failing somewhere in
> > pci probe. My olde-fashioned, slow, but-usually-works method is to
> > sprinkle enough printk's into the code to catch it in the act.
> I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
> some printk's into the code?
The last identifiable message I was
<7>PCI: Calling quirk...
which is from drivers/pci/quirks.c
...CI: Found 0000:00:07.2 [1106/303...
and this is from pci_setup_device() in drivers/pci/probe.c So I'd look
to see if pci_setup_device() ever returned, and then I'd look to see
what happened next.
--linas
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-09-27 22:10 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927220022.GC18686@austin.ibm.com>
On Thu, Sep 27, 2007 at 05:00:22PM -0500, Linas Vepstas wrote:
> On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> > I'm a little concerned by the mention of MMIO. It's entirely possible
> > for the sym2 driver to be using ioports to access the card rather than
> > MMIO. Is it simply that it can't on the platform you test on?
>
> The comment is misleading. I've been in the bad habit of calling
> it "mmio" whenever its not DMA.
OK, cool, thanks. I'll update the comment for you.
One last thing (sorry, I only just noticed):
In the error handler, we wait_for_completion(io_reset_wait).
In sym2_io_error_detected, we init_completion(io_reset_wait).
Isn't it possible that we hit the error handler before we hit the
io_error_detected path, and thus the completion wait is lost?
Since the completion is already initialised in sym_attach(), I don't
think we need to initialise it in sym2_io_error_detected().
Makes sense to just delete it?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 22:08 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.202207.-1300525707.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 20:22 +0900, Ishizaki Kou wrote:
> Ben-san,
>
> > On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
> >
> > > Celleb does not set get_paca()->kstack properly (I don't know which
> > > function should set it up), so we need to workaround.
> >
> > paca->kstack is set in asm (via the PACAKSAVE macro), from either
> > __secondary_start for non-boot CPUs or from start_here_common for the
> > boot CPU.
> >
> > slb_flush_and_rebolt() should not be called before that happens.
> >
> > How do you end up with kstack set to 0 ?
>
> I found r13 is not set before entering start_here_common for boot cpu.
> For non-boot threads, __secondary_start will set r13 properly.
>
> So the problem is to set r13 correct PACA address before entering
> start_here_common. Should it set before entering kernel or will some
> patch make sense?
That is scary... we seem to have lost an mfsprg r13,SPRN_SPRG3 somewhere
along the way, I'm surprised things boot at all, or maybe I'm missing
something here... Paul ?
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-09-27 22:00 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070926150216.GH3899@parisc-linux.org>
On Wed, Sep 26, 2007 at 09:02:16AM -0600, Matthew Wilcox wrote:
> On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> > Implement the so-called "first failure data capture" (FFDC) for the
> > symbios PCI error recovery. After a PCI error event is reported,
> > the driver requests that MMIO be enabled. Once enabled, it
> > then reads and dumps assorted status registers, and concludes
> > by requesting the usual reset sequence.
>
> > + /* Request that MMIO be enabled, so register dump can be taken. */
> > + return PCI_ERS_RESULT_CAN_RECOVER;
> > +}
>
> I'm a little concerned by the mention of MMIO. It's entirely possible
> for the sym2 driver to be using ioports to access the card rather than
> MMIO. Is it simply that it can't on the platform you test on?
The comment is misleading. I've been in the bad habit of calling
it "mmio" whenever its not DMA.
The habit is because there are two distinct enable bits in the
pci-host bridge during error recovery: one to enable mmio/ioports,
and the other to enable DMA. If the adapter has gone crazy, I don't
want to enable DMA, so that it doesn't scribble to bad places. But,
by enabling mmio/ioports, perhaps it can be finessed back into a
semi-sane state, e.g. sane enough to perform a dump of its internal
state.
--linas
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 21:57 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927213503.GA18686@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 16:35:03 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> >
> > Do you have an idea how to debug it?
>
> Not particularly. What caught my eye was the failure right near the
> PCI quirk stuff, as I was having problems there as well (but apearntly,
> for very different reasons).
Yes, I also suspect the PCI code. The AmigaOne has a VIA southbridge.
AFAIK there were some changes in the PCI quirks for VIA chipsets, but so
far I couldn't see any significant changes in the code.
> Based on your boot messages, it looks like you are failing somewhere in
> pci probe. My olde-fashioned, slow, but-usually-works method is to
> sprinkle enough printk's into the code to catch it in the act.
I guess the code in arch/powerpc/pci*.c is the right place to sprinkle
some printk's into the code?
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Kumar Gala @ 2007-09-27 21:40 UTC (permalink / raw)
To: ljd015; +Cc: linuxppc-embedded
In-Reply-To: <11909173512321-git-send-email-ljd015@freescale.com>
On Sep 27, 2007, at 1:22 PM, ljd015@freescale.com wrote:
> From: Joe D'Abbraccio <ljd015@freescale.com>
>
> The MPC837x RDB is a new member of the Freescale MPC83xx reference
> design
> boards.
>
> Signed-off-by: Joe D'Abbraccio <ljd015@freescale.com>
Please base your patch against an external tree (like my for-2.6.24
branch).
See comments inline.
- k
> ---
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 306 ++++++++++
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 286 +++++++++
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 281 +++++++++
> arch/powerpc/configs/mpc837x_rdb_defconfig | 886 +++++++++++++++++
> +++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 8 +-
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/mpc837x_rdb.c | 102 ++++
> 7 files changed, 1869 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8377_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8378_rdb.dts
> create mode 100644 arch/powerpc/boot/dts/mpc8379_rdb.dts
> create mode 100644 arch/powerpc/configs/mpc837x_rdb_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/mpc837x_rdb.c
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/
> boot/dts/mpc8377_rdb.dts
> new file mode 100644
> index 0000000..1ee2a06
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
> @@ -0,0 +1,306 @@
> +/*
> + * MPC8377E RDB Device Tree Source
> + *
> + * Copyright 2005, 2006, 2007 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +/ {
> + model = "fsl,mpc8377erdb";
> + compatible = "fsl,mpc8377erdb","fsl,mpc837xrdb";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,837x@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>;
> + i-cache-line-size = <20>;
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 10000000>; // 256MB at 0
> + };
> +
> + soc837x@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 e0000000 00100000>;
> + reg = <e0000000 00000200>;
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
> + compatible = "mpc83xx_wdt";
> + reg = <200 100>;
> + };
> +
> + i2c@3000 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3000 100>;
> + interrupts = <e 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <3100 100>;
> + interrupts = <f 8>;
> + interrupt-parent = < &ipic >;
> + dfsrr;
> + };
> +
> + spi@7000 {
> + device_type = "spi";
> + compatible = "mpc83xx_spi";
> + reg = <7000 1000>;
> + interrupts = <10 8>;
> + interrupt-parent = < &ipic >;
> + mode = <0>;
> + };
> +
> + /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> + usb@23000 {
> + device_type = "usb";
> + compatible = "fsl-usb2-dr";
> + reg = <23000 1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupt-parent = < &ipic >;
> + interrupts = <26 8>;
> + phy_type = "utmi_wide";
> + };
> +
> + mdio@24520 {
> + device_type = "mdio";
> + compatible = "gianfar";
> + reg = <24520 20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy2: ethernet-phy@2 {
> + interrupt-parent = < &ipic >;
> + interrupts = <11 8>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@3 {
> + interrupt-parent = < &ipic >;
> + interrupts = <12 8>;
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <20 8 21 8 22 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy2 >;
> + };
> +
> + ethernet@25000 {
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <23 8 24 8 25 8>;
> + phy-connection-type = "mii";
> + interrupt-parent = < &ipic >;
> + phy-handle = < &phy3 >;
> + };
> +
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <9 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + pci@9000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <9000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <1 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
> + pci@a000 {
> + device_type = "pci";
> + compatible = "fsl,mpc83xx-pex";
> + reg = <a000 1000>;
> + interrupt-parent = < &ipic >;
> + interrupts = <2 8>;
> + phy-handle = < &serdes2 >;
> + };
> +
remove these pci nodes since we don't have kernel support for pex on
83xx.
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
> + reg = <30000 7000>;
> + interrupts = <b 8>;
> + interrupt-parent = < &ipic >;
> + /* Rev. 2.2 */
> + num-channels = <1>;
> + channel-fifo-len = <18>;
> + exec-units-mask = <0000004c>;
> + descriptor-types-mask = <0122003f>;
> + };
> +
> + sdhc@2e000 {
> + model = "eSDHC";
> + compatible = "fsl,esdhc";
> + reg = <2e000 1000>;
> + interrupts = <2a 8>;
> + interrupt-parent = < &ipic >;
> + };
> +
> + sata@18000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <18000 1000>;
> + interrupts = <2c 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + sata@19000 {
> + device_type = "sata";
> + model = "SATA-300";
> + compatible = "fsl,sata300";
> + reg = <19000 1000>;
> + interrupts = <2d 8>;
> + interrupt-parent = < &ipic >;
> + phy-handle = < &serdes1 >;
> + };
> +
> + serdes1:serdes@e3000 {
> + compatible = "fsl,serdes";
> + reg = <e3000 100>;
> + vdd-1v;
> + protocol = "sata";
> + clock = <d#100>;
> + };
> +
> + serdes2:serdes@e3100 {
> + model = "SerDes";
> + compatible = "fsl,serdes";
> + reg = <e3100 100>;
> + vdd-1v;
> + protocol = "pex";
> + clock = <d#100>;
> + };
remove sata, sdhc, and serdes until the device binding patches that
describe these are posted.
> +
> + /* IPIC
> + * interrupts cell = <intr #, sense>
> + * sense values match linux IORESOURCE_IRQ_* defines:
> + * sense == 8: Level, low assertion
> + * sense == 2: Edge, high-to-low change
> + */
> + ipic: pic@700 {
> + compatible = "fsl,ipic";
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <700 100>;
> + };
> + };
> +
> + pci@e0008500 {
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> +
> + /* IDSEL 0x11 */
> + 8800 0 0 1 &ipic 14 8
> + 8800 0 0 2 &ipic 15 8
> + 8800 0 0 3 &ipic 16 8
> + 8800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x12 */
> + 9000 0 0 1 &ipic 16 8
> + 9000 0 0 2 &ipic 17 8
> + 9000 0 0 3 &ipic 14 8
> + 9000 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x13 */
> + 9800 0 0 1 &ipic 17 8
> + 9800 0 0 2 &ipic 14 8
> + 9800 0 0 3 &ipic 15 8
> + 9800 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x15 */
> + a800 0 0 1 &ipic 14 8
> + a800 0 0 2 &ipic 15 8
> + a800 0 0 3 &ipic 16 8
> + a800 0 0 4 &ipic 17 8
> +
> + /* IDSEL 0x16 */
> + b000 0 0 1 &ipic 17 8
> + b000 0 0 2 &ipic 14 8
> + b000 0 0 3 &ipic 15 8
> + b000 0 0 4 &ipic 16 8
> +
> + /* IDSEL 0x17 */
> + b800 0 0 1 &ipic 16 8
> + b800 0 0 2 &ipic 17 8
> + b800 0 0 3 &ipic 14 8
> + b800 0 0 4 &ipic 15 8
> +
> + /* IDSEL 0x18 */
> + c000 0 0 1 &ipic 15 8
> + c000 0 0 2 &ipic 16 8
> + c000 0 0 3 &ipic 17 8
> + c000 0 0 4 &ipic 14 8>;
> + interrupt-parent = < &ipic >;
> + interrupts = <42 8>;
> + bus-range = <0 0>;
> + ranges = <02000000 0 90000000 90000000 0 10000000
> + 42000000 0 80000000 80000000 0 10000000
> + 01000000 0 00000000 e2000000 0 00100000>;
> + clock-frequency = <0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <e0008500 100>;
> + compatible = "fsl,mpc83xx-pci", "83xx";
> + device_type = "pci";
> + };
> +};
(above comments apply to other .dts)
[snip]
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> platforms/83xx/Kconfig
> index 0c61e7a..76a623b 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -55,6 +55,12 @@ config MPC837x_MDS
> select DEFAULT_UIMAGE
> help
> This option enables support for the MPC837x MDS Processor Board.
> +
> +config MPC837x_RDB
> + bool "Freescale MPC837x RDB"
> + select DEFAULT_UIMAGE
> + help
> + This option enables support for the MPC837x RDB Board.
> endchoice
>
> config PPC_MPC831x
> @@ -86,4 +92,4 @@ config PPC_MPC837x
> select PPC_UDBG_16550
> select PPC_INDIRECT_PCI
> select FSL_SERDES
FSL_SERDES doesn't exist in any tree at this point.
> - default y if MPC837x_MDS
> + default y if MPC837x_MDS || MPC837x_RDB
> diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/
> platforms/83xx/Makefile
> index df46629..d64c0ad 100644
> --- a/arch/powerpc/platforms/83xx/Makefile
> +++ b/arch/powerpc/platforms/83xx/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
> obj-$(CONFIG_MPC836x_MDS) += mpc836x_mds.o
> obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
> obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
> +obj-$(CONFIG_MPC837x_RDB) += mpc837x_rdb.o
This patch will not apply since 837x_MDS doesn't exist.
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/
> powerpc/platforms/83xx/mpc837x_rdb.c
> new file mode 100644
> index 0000000..132438f
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
> @@ -0,0 +1,102 @@
> +/*
> + * arch/powerpc/platforms/83xx/mpc837x_rdb.c
> + *
> + * Copyright (C) 2007 Freescale Semicondutor, Inc. All rights
> reserved.
> + *
> + * MPC837x RDB board specific routines
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/of_platform.h>
> +
> +#include <asm/time.h>
> +#include <asm/ipic.h>
> +#include <asm/udbg.h>
> +
> +#include "mpc83xx.h"
> +
> +#ifndef CONFIG_PCI
> +unsigned long isa_io_base;
> +unsigned long isa_mem_base;
> +#endif
> +
> +/*
> **********************************************************************
> **
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init mpc837x_rdb_setup_arch(void)
> +{
> +#ifdef CONFIG_PCI
> + struct device_node *np;
> +#endif
> +
> + if (ppc_md.progress)
> + ppc_md.progress("mpc837x_rdb_setup_arch()", 0);
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
This should be somethine like:
for_each_node_by_type(np, "pci")
if (of_device_is_compatible(np, "fsl,mpc83xx-pci"))
add_bridge(np);
> +#endif
> +}
> +
> +static struct of_device_id mpc837x_ids[] = {
> + { .type = "soc", },
> + { .compatible = "soc", },
> + {},
> +};
> +
> +static int __init mpc837x_declare_of_platform_devices(void)
> +{
> + if (!machine_is(mpc837x_rdb))
> + return 0;
> +
> + /* Publish of_device */
> + of_platform_bus_probe(NULL, mpc837x_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(mpc837x_declare_of_platform_devices);
> +
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
> +
> + /* Initialize the default interrupt mapping priorities,
> + * in case the boot rom changed something on us.
> + */
> + ipic_set_default_priority();
> +}
> +
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc837xrdb");
> +}
> +
> +define_machine(mpc837x_rdb) {
> + .name = "MPC837x RDB",
> + .probe = mpc837x_rdb_probe,
> + .setup_arch = mpc837x_rdb_setup_arch,
> + .init_IRQ = mpc837x_rdb_init_IRQ,
> + .get_irq = ipic_get_irq,
> + .restart = mpc83xx_restart,
> + .time_init = mpc83xx_time_init,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> +};
> --
> 1.5.2.2
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 21:35 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927211700.201970@gmx.net>
On Thu, Sep 27, 2007 at 11:17:00PM +0200, Gerhard Pircher wrote:
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
>
> Do you have an idea how to debug it?
Not particularly. What caught my eye was the failure right near the
PCI quirk stuff, as I was having problems there as well (but apearntly,
for very different reasons). Based on your boot messages, it looks
like you are failing somewhere in pci probe. My olde-fashioned, slow,
but-usually-works method is to sprinkle enough printk's into the code
to catch it in the act.
--linas
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Kumar Gala @ 2007-09-27 21:31 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927195351.GE7838@mag.az.mvista.com>
On Sep 27, 2007, at 2:53 PM, Mark A. Greer wrote:
> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015
> wrote:
>> Thanks for the advice, but I was just basing the list to post to
>> on the
>> MAINTAINERS file which states that this is the one for Embedded
>> PPC83XX.
>> If you still think that I should post to linuxppc-dev, let me know.
>
> Yes, I think it would be better to repost to linuxppc-dev.
>
> Does anyone have an objection to changing all of the:
>
> "L: linuxppc-embedded@ozlabs.org"
>
> in MAINTAINERS to:
>
> "L: linuxppc-dev@ozlabs.org" ??
>
> Kumar, Josh, Vitaly, et. al.?
I'm all for it, but we should see about killing linuxppc-embedded and
just move everyone to linuxppc-dev.
- k
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Olof Johansson @ 2007-09-27 21:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927150312.4eea96fd@weaponx.rchland.ibm.com>
On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> On Thu, 27 Sep 2007 12:53:51 -0700
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> > On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > > Thanks for the advice, but I was just basing the list to post to on the
> > > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > > If you still think that I should post to linuxppc-dev, let me know.
> >
> > Yes, I think it would be better to repost to linuxppc-dev.
> >
> > Does anyone have an objection to changing all of the:
> >
> > "L: linuxppc-embedded@ozlabs.org"
> >
> > in MAINTAINERS to:
> >
> > "L: linuxppc-dev@ozlabs.org" ??
> >
> > Kumar, Josh, Vitaly, et. al.?
>
> I personally don't care either way. I'm already subscribed to both
> lists.
>
> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
I thought the -embedded list was created in the first place to keep some
of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
my custom <embedded eval board>-lookalike board, HELP!"). If people still
care about keeping that on a separate list, then we shouldn't change it.
I think the relevant people probably monitor this list (maybe not quite as
frequently) to catch things. I even caught the first PWRficient-related
question in a timely manner the other day. :-)
Still, that being said, patches will clearly get better exposure on -dev,
especially device tree crap.
-Olof
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-27 21:17 UTC (permalink / raw)
To: linas; +Cc: linuxppc-dev
In-Reply-To: <20070927205012.GN7970@austin.ibm.com>
-------- Original-Nachricht --------
> Datum: Thu, 27 Sep 2007 15:50:12 -0500
> Von: linas@austin.ibm.com
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> On Thu, Sep 27, 2007 at 09:31:31PM +0200, Gerhard Pircher wrote:
> >
> > > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> > > >
> > > > I'm working on a 2.6.23 kernel for the AmigaOne.
>
> Have you tried 2.6.22, or does that fail also?
>
> --linas
No, not yet. The last kernel that is working on the AmigaOne is a 2.6.16.x
kernel (still arch/ppc). All further kernels (2.6.17 and 2.6.18) that I
compiled with the old platform code for arch/ppc showed a similar
behavior. I hoped that this would only be a side effect of the ppc ->
powerpc transition. I also tried to search through the changelog files
to find an indication for the problem.
Do you have an idea how to debug it?
I guess it would be possible with a JTAG debugger, but the AmigaOne is
a desktop system and I don't know, if the JTAG pins of the CPU are
accessible on the board.
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: changing the EDLK components
From: Wolfgang Denk @ 2007-09-27 21:16 UTC (permalink / raw)
To: Murat Artun; +Cc: linuxppc-embedded
In-Reply-To: <4e5a3720709270734k54016e93h68ae6606d959cee9@mail.gmail.com>
In message <4e5a3720709270734k54016e93h68ae6606d959cee9@mail.gmail.com> you wrote:
>
> Specifically, I have followed the procedure in section "3.7.
> Rebuilding ELDK Components". First I have installed source RPMs and
> then rebuilt the binary target RPM. However, as I have followed the
> compiler messages I recognized that host gcc is called instead of
> cross gcc.
>
> Considering that my PATH was set following the advice in section "3.7.
> Rebuilding ELDK Components" as "<ELDK_root>/usr/ppc-linux/bin"
> directory is before "/usr/bin" what could be the problem?
If you really followed that advice then please explain how the native
gcc could be called at all because the cross compiler will always be
found first in the PATH?
I recommend checking the documentation again and following it step by
step.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?"
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Linas Vepstas @ 2007-09-27 20:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070927193131.201920@gmx.net>
On Thu, Sep 27, 2007 at 09:31:31PM +0200, Gerhard Pircher wrote:
>
> > Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> > >
> > > I'm working on a 2.6.23 kernel for the AmigaOne.
Have you tried 2.6.22, or does that fail also?
--linas
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Josh Boyer @ 2007-09-27 20:03 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927195351.GE7838@mag.az.mvista.com>
On Thu, 27 Sep 2007 12:53:51 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > Thanks for the advice, but I was just basing the list to post to on the
> > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > If you still think that I should post to linuxppc-dev, let me know.
>
> Yes, I think it would be better to repost to linuxppc-dev.
>
> Does anyone have an objection to changing all of the:
>
> "L: linuxppc-embedded@ozlabs.org"
>
> in MAINTAINERS to:
>
> "L: linuxppc-dev@ozlabs.org" ??
>
> Kumar, Josh, Vitaly, et. al.?
I personally don't care either way. I'm already subscribed to both
lists.
Makes sense to go to linuxppc-dev given the arch/powerpc migration.
josh
^ 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