* Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Mohammad Sadegh Sadri @ 2007-05-29 14:41 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi all,
well I could bring up the grant's kernel on ml403 completely. the root file=
system was over nfs.=20
when I use a 100mbits link for connection to ml403 , every thing is working=
suitably.
but when I use a 1000mbits link, I see that ml403 gets ip address from dhcp=
and mounts the root file system but can not go further , it stops with a m=
essage: "nfs server not responding ...." some thing like this.
when pinging to ml403 with 64 bytes packets, ping works fine for both of 10=
0 and 1000mbits links
but when I try to ping the board with 4000 bytes packets I notice that ml40=
3 on gigabit link can not answer to ping packets, however on 100mbit link e=
very thing works just fine.
any ideas?
_________________________________________________________________
Connect to the next generation of MSN Messenger=A0
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc=
e=3Dwlmailtagline=
^ permalink raw reply
* Re: [PATCH] Powerpc compiler error fix for 2.6.21-rt8
From: Sergei Shtylyov @ 2007-05-29 14:41 UTC (permalink / raw)
To: Pradyumna Sampath; +Cc: linux-rt-users, linuxppc-embedded
In-Reply-To: <f87351060705282124q6d6b1562ic1dd4da4b8a62886@mail.gmail.com>
Hello.
Pradyumna Sampath wrote:
> Attached is a small patch to fix compile time errors which is broken
> in 2.6.21-rt8 for powerpc.
NAK. It's been deleted on purpose (not used anymore), and I've already
sent a patch to kill the leftover reference.
> ------------------------------------------------------------------------
>
> diff -ur latest/linux-2.6.21/arch/powerpc/kernel/time.c linux-2.6.21/arch/powerpc/kernel/time.c
> --- latest/linux-2.6.21/arch/powerpc/kernel/time.c 2007-05-29 09:58:12.000000000 +0530
> +++ linux-2.6.21/arch/powerpc/kernel/time.c 2007-05-29 08:58:56.000000000 +0530
> @@ -95,6 +95,8 @@
> #define SCALE_XSEC(xsec, max) mulhwu((xsec) << 12, max)
> #endif
>
> +unsigned long cpu_khz; /* Detected as we calibrate the TSC */
> +EXPORT_SYMBOL(cpu_khz);
> unsigned long tb_ticks_per_jiffy;
> unsigned long tb_ticks_per_usec = 100; /* sane default */
> EXPORT_SYMBOL(tb_ticks_per_usec);
> Only in linux-2.6.21/arch/powerpc/kernel: vmlinux.lds
> Only in linux-2.6.21/scripts/kconfig: mconf
Please cut off such garbage from yoour patches...
WBR, Sergei
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 14:38 UTC (permalink / raw)
To: Kumar Gala
Cc: Ulrich Weigand, Paul Mackerras, Steve Munroe, Anton Blanchard,
linuxppc-dev list
In-Reply-To: <40815D64-3AD7-49C6-9A58-C7848691D940@kernel.crashing.org>
> But we can't do that any more since the architecture specifically
> allows for the 'upper bits' not to have valid data in them.
That's not PowerPC, that's BookE ;-P If what you're
saying is true in the 2.03 POWER ISA, even for server
class implementations, that would be very unfortunate.
Or perhaps you misread, there are a few insns that
have undefined results in the high half word. Could
you give a reference please?
If you mean Book I 1.5.2, that is for embedded class
(i.e., BookE) CPUs only.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 14:31 UTC (permalink / raw)
To: Ulrich Weigand
Cc: Steve Munroe, linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <OF462E078D.FFB634FD-ON422572EA.004D1E28-422572EA.004DB265@de.ibm.com>
> > We don't need another ABI change to powerpc32 (still recovering=20
> from the
> > -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
> >
> > ABI changes ripple everywhere (not just GCC/GLIBC) including all=20
> debuggers
> > and performance tools. Believe me you really don't want this.
>
> Fully agreed. =A0This may have gotten lost in the discussion thread, =
but=20
> what
> Ben originally proposed was *not* an ABI change, for exactly that=20
> reason.
> We simply want to allow strictly local use of 64-bit registers for
> performance optimization purposes, while still fully complying with
> the 32-bit ABI.
Some stuff gets added to the user version of the signal
frame; is that not an ABI change? Quite possibly a
(supposedly) compatible change, but a change anyway.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 14:28 UTC (permalink / raw)
To: Steve Munroe
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <OF23D1348F.B2E0AE28-ON862572EA.004C17B2-862572EA.004CF843@us.ibm.com>
>>>> - how can an application know that it can use 64 bit registers and
>>>> call
>>>> the optimized routines?
>>>
>>> I'd say use the 32 bits ABI, AT_HWCAP will tell you if you are
>>> running
>>> on a 64 bits capable machine. You can then either use hand tuned code
>>> at
>>> runtime, or I think ld.so can load alternate libs based on the bits
>>> in
>>> there.
>>
>> Or you can simply only install 64-bit binaries on 64-bit
>> machines.
>>
> Yes exactly why make an incompatible ABI change to the powerp32 ABI,
> when
> you can just use the existing 64-bit ABI.
I meant programs using 64-bit insns while running in the
32-bit personality when I said "64-bit binaries". No ABI
change is necessary, except very few applications might
want to look at saved registers.
Plain 64-bit programs using 32 bits of address space only
is a much nicer idea indeed. And it doesn't even need
an ABI change! Just a new kernel personality (or an ELF
header flag or whatever).
> Especially as you can only run what is proposed on 64-bit hardware!
>
> We don't need another ABI change to powerpc32 (still recovering from
> the
> -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
>
> ABI changes ripple everywhere (not just GCC/GLIBC) including all
> debuggers
> and performance tools. Believe me you really don't want this.
I've had to deal with exactly this on Darwin before, and
although that was as a simple user only, I can confirm:
I really do not want it. Unless it magically would be
100% stable at once of course :-)
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Arnd Bergmann @ 2007-05-29 14:28 UTC (permalink / raw)
To: linuxppc-dev
Cc: Steve Munroe, Ulrich Weigand, Paul Mackerras, Anton Blanchard
In-Reply-To: <08b3997ab86a819c63b5cb0afcdc0c9e@kernel.crashing.org>
On Tuesday 29 May 2007, Segher Boessenkool wrote:
> > But it also makes me wonder about a few things:
> > - do you use the standard 32 bit ABI, in which case the caller of
> > libraries
> > does not care and the libraries can be put in the standard places,
>
> The compiler should either a) use full 64-bit only for
> "volatile" (call-clobbered) registers, or b) save and
> restore other 64-bit mode registers around calls. I don't
> remember if powerpc-linux-gcc does a) or b), if either.
As benh explained, the 64 bit register contents are maintained
over normal function calls, iirc the ABI treats the upper halves
of each register as call-clobbered.
The problem is really just signal handlers.
> > or are
> > there cases where the ability to pass 64 bit values in a single
> > register would improve performance to the point that it is worth
> > having an incompatible library (where to put it and how to name it)?
>
> That would be a third ABI. Is it worth that?
no ;-)
> > - how can an application know that it can use 64 bit registers and call
> > the optimized routines?
>
> Just call them and trap the SEGV ;-) You can check the
> aux vector of course, or ask glibc -- but the SEGV way
> is the only really portable way. Strange world :-)
shouldn't that be SIGILL?
> > As long
> > as such an option does not exist, the usefulness of this feature is
> > somewhat limited. In other words, GCC for now has support for ILP32 and
> > LP64 modes, but it would be better to also have support for IP32L64.
>
> ILP32LL64. The C "mode" stays the same, only the generated
> machine insns are changed.
right, as mentioned before, IP32L64 would imply introducing a new
ABI, which we don't want.
Arnd <><
^ permalink raw reply
* Re: Don't use HOSTCFLAGS in BOOTCFLAGS
From: Josh Boyer @ 2007-05-29 14:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070529053712.GE30266@localhost.localdomain>
On Tue, 2007-05-29 at 15:37 +1000, David Gibson wrote:
> In the bootwrapper code for powerpc, we include HOSTCFLAGS into the
> BOOTCFLAGS used for buildinf the zImage wrapper code. Since the
> wrapper code is not host code, this makes no sense. This patch
> removes the use of HOSTCFLAGS here, instead including directly into
> BOOTCFLAGS those flags from the normal kernel CFLAGS which also make
> sense in the bootwrapper code.
>
> In particular, this makes the bootwrapper use -msoft-float, preventing
> the compiler from generating floating point instructions. Previously,
> under some circumstances the compiler could generate floating point
> instructions in the bootwrapper which would cause exceptions on
> embedded CPUS which don't have floating point support.
This is essentially the cleanup Paul asked me to do of my original
-msoft-float addition. Matches the patch I have sitting locally that I
haven't gotten around to sending out yet.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] fix compile warning in pseries xics
From: Olof Johansson @ 2007-05-29 14:27 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <4564.1180422112@neuling.org>
On Tue, May 29, 2007 at 05:01:52PM +1000, Michael Neuling wrote:
> @@ -762,11 +763,12 @@ void xics_request_IPIs(void)
> */
> set_irq_handler(ipi, handle_percpu_irq);
> if (firmware_has_feature(FW_FEATURE_LPAR))
> - request_irq(ipi, xics_ipi_action_lpar, IRQF_DISABLED,
> - "IPI", NULL);
> + rc = request_irq(ipi, xics_ipi_action_lpar, IRQF_DISABLED,
> + "IPI", NULL);
> else
> - request_irq(ipi, xics_ipi_action_direct, IRQF_DISABLED,
> - "IPI", NULL);
> + rc = request_irq(ipi, xics_ipi_action_direct, IRQF_DISABLED,
> + "IPI", NULL);
> + BUG_ON(rc);
Is this late enough during boot that you actually get useful information
out of a BUG()? It might be better to spit out an error and keep on
going if that's the case (I'm afraid I don't have hardware at hand to
test with right now).
-Olof
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-29 14:19 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Alexandre Bounine, Paul Mackerras,
David Gibson
In-Reply-To: <c7c131c3a7fdf7727d9ea1e40775017a@kernel.crashing.org>
On Tue, 2007-05-29 at 08:43 +0200, Segher Boessenkool wrote:
> > + MDIO: mdio@6000 {
> > device_type = "mdio";
> > - compatible = "tsi-ethernet";
> > + compatible = "tsi-mdio";
>
> Hrm, did I miss this before? A more exact "compatible"
> property would be better ("tsi109-mdio" "tsi108-mdio" or
> something like that).
If we must, then tsi108-mdio is what I would recommend. They are the
same between 108, 109, and 110 as far as I know, so it's the lowest
common denominator.
josh
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Kumar Gala @ 2007-05-29 14:17 UTC (permalink / raw)
To: Ulrich Weigand
Cc: linuxppc-dev list, Paul Mackerras, Steve Munroe, Anton Blanchard
In-Reply-To: <OF462E078D.FFB634FD-ON422572EA.004D1E28-422572EA.004DB265@de.ibm.com>
On May 29, 2007, at 9:08 AM, Ulrich Weigand wrote:
>
> Steve Munroe <sjmunroe@us.ibm.com> wrote on 05/29/2007 04:00:42 PM:
>
> > Yes exactly why make an incompatible ABI change to the powerp32
> ABI, when
> > you can just use the existing 64-bit ABI.
> >
> > Especially as you can only run what is proposed on 64-bit hardware!
> >
> > We don't need another ABI change to powerpc32 (still recovering
> from the
> > -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
> >
> > ABI changes ripple everywhere (not just GCC/GLIBC) including all
> debuggers
> > and performance tools. Believe me you really don't want this.
>
> Fully agreed. This may have gotten lost in the discussion thread,
> but what
> Ben originally proposed was *not* an ABI change, for exactly that
> reason.
> We simply want to allow strictly local use of 64-bit registers for
> performance optimization purposes, while still fully complying with
> the 32-bit ABI.
But we can't do that any more since the architecture specifically
allows for the 'upper bits' not to have valid data in them.
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Ulrich Weigand @ 2007-05-29 14:08 UTC (permalink / raw)
To: Steve Munroe; +Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard
In-Reply-To: <OF23D1348F.B2E0AE28-ON862572EA.004C17B2-862572EA.004CF843@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Steve Munroe <sjmunroe@us.ibm.com> wrote on 05/29/2007 04:00:42 PM:
> Yes exactly why make an incompatible ABI change to the powerp32 ABI,
when
> you can just use the existing 64-bit ABI.
>
> Especially as you can only run what is proposed on 64-bit hardware!
>
> We don't need another ABI change to powerpc32 (still recovering from the
> -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
>
> ABI changes ripple everywhere (not just GCC/GLIBC) including all
debuggers
> and performance tools. Believe me you really don't want this.
Fully agreed. This may have gotten lost in the discussion thread, but
what
Ben originally proposed was *not* an ABI change, for exactly that reason.
We simply want to allow strictly local use of 64-bit registers for
performance optimization purposes, while still fully complying with
the 32-bit ABI.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
GNU compiler/toolchain for Linux on System z and Cell BE
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #2: Type: text/html, Size: 1661 bytes --]
^ permalink raw reply
* Re: How can I get a ramdisk.image for linux2.6 running on ML403?
From: Grant Likely @ 2007-05-29 14:01 UTC (permalink / raw)
To: angelalinyao@163.com; +Cc: Linuxppc-embedded
In-Reply-To: <2547937.196031180424819306.JavaMail.nabble@isper.nabble.com>
On 5/29/07, angelalinyao@163.com <angelalinyao@163.com> wrote:
> Is there any ramdisk.image provided for linux 2.6?Or maybe I have to make a ramdisk by myself?If I make a ramdisk by myself,where can I get all the files under dev/?Will the dev/ simply copied from a server or PC which runs linux 2.6 work for ppc405?
> Any help from you is appreciated.Thank you!
If you just want an out-of-the-box ramdisk, you can use the one in ELDK
http://www.denx.de/wiki/DULG/ELDK
Or, you can mount your existing ramdisk image on another Linux box and
copy the needed files over. The /dev entries are the same across all
architectures.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-29 14:00 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <710cb04ed3b82b11192cf54aa08c0230@kernel.crashing.org>
Segher Boessenkool <segher@kernel.crashing.org> wrote on 05/29/2007
08:12:24 AM:
> >> - how can an application know that it can use 64 bit registers and
> >> call
> >> the optimized routines?
> >
> > I'd say use the 32 bits ABI, AT_HWCAP will tell you if you are running
> > on a 64 bits capable machine. You can then either use hand tuned code
> > at
> > runtime, or I think ld.so can load alternate libs based on the bits in
> > there.
>
> Or you can simply only install 64-bit binaries on 64-bit
> machines.
>
Yes exactly why make an incompatible ABI change to the powerp32 ABI, when
you can just use the existing 64-bit ABI.
Especially as you can only run what is proposed on 64-bit hardware!
We don't need another ABI change to powerpc32 (still recovering from the
-msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
ABI changes ripple everywhere (not just GCC/GLIBC) including all debuggers
and performance tools. Believe me you really don't want this.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Ulrich Weigand @ 2007-05-29 13:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard, Steve Munroe
In-Reply-To: <1180423456.19517.124.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 05/29/2007
09:24:15 AM:
> Specifically, are everybody using the uc_regs pointer to get to the
> mcontext or are some people likely to expect the mcontext to always be
> at the same offset from the beginning of the signal frame ?
As far as I can see, both GDB and the GCC unwind-from-signal code
always read the uc_regs pointer. (Or the sigcontext.regs pointer for
old-style signal frames.)
> There are a few other issues... one is, the pad fields aren't cleared.
> Thus how can userland or rt_sigreturn differenciate between a valid
> highregs pointers and ramdom junk ? Is there a trick one of you can come
> up with that I could do to let userland/gdb/rt_sigreturn know that
> there's something there ?
One idea we had about this was to use a bit in uc_flags. Those are
completely unused today, but should always have been initialized to 0.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
GNU compiler/toolchain for Linux on System z and Cell BE
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #2: Type: text/html, Size: 1779 bytes --]
^ permalink raw reply
* Re: pcimsg patch from eons ago
From: Grant Likely @ 2007-05-29 13:37 UTC (permalink / raw)
To: Adrian Cox; +Cc: Linux PPC
In-Reply-To: <1180422549.4829.5.camel@localhost.localdomain>
On 5/29/07, Adrian Cox <adrian@humboldt.co.uk> wrote:
> I can't find that version, but I have found a later version:
> http://www.humboldt.co.uk/files/pcimsg_20020307.tar.gz
>
Cool, thanks Adrian
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Ulrich Weigand @ 2007-05-29 13:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <C31B9167-94B6-48B4-9529-78702E962460@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
Kumar Gala <galak@kernel.crashing.org> wrote on 05/29/2007 03:19:42 PM:
> On May 29, 2007, at 4:02 AM, Benjamin Herrenschmidt wrote:
> > Hrm.. we do have a subtle difference in vrregs that I've missed.. I'll
> > respin tomorrow. It looks like we don't store the VRSAVE register
> > at the
> > same place on 32 and 64 bits... yuck. I need to double check tomorrow.
>
> That's bad. We really should have VRSAVE in the same location for
> both. (wondering if GDB expects it a different locations on 32 vs 64-
> bits.)
It looks like GDB will expect VRSAVE at offset 33*16 (length 4 bytes)
in the area returned by PTRACE_GETVRREGS, for both 32-bit and 64-bit
applications:
/* This oddity is because the Linux kernel defines elf_vrregset_t as
an array of 33 16 bytes long elements. I.e. it leaves out vrsave.
However the PTRACE_GETVRREGS and PTRACE_SETVRREGS requests return
the vrsave as an extra 4 bytes at the end. I opted for creating a
flat array of chars, so that it is easier to manipulate for gdb.
There are 32 vector registers 16 bytes longs, plus a VSCR register
which is only 4 bytes long, but is fetched as a 16 bytes
quantity. Up to here we have the elf_vrregset_t structure.
Appended to this there is space for the VRSAVE register: 4 bytes.
Even though this vrsave register is not included in the regset
typedef, it is handled by the ptrace requests.
Note that GNU/Linux doesn't support little endian PPC hardware,
therefore the offset at which the real value of the VSCR register
is located will be always 12 bytes.
The layout is like this (where x is the actual value of the vscr reg):
*/
/* *INDENT-OFF* */
/*
|.|.|.|.|.....|.|.|.|.||.|.|.|x||.|
<-------> <-------><-------><->
VR0 VR31 VSCR VRSAVE
*/
/* *INDENT-ON* */
#define SIZEOF_VRREGS 33*16+4
typedef char gdb_vrregset_t[SIZEOF_VRREGS];
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
GNU compiler/toolchain for Linux on System z and Cell BE
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #2: Type: text/html, Size: 3794 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 4/5] powerpc: Make syscall restart code more common
From: Kumar Gala @ 2007-05-29 13:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, ulrich.weigand, Paul Mackerras, Christoph Hellwig,
Anton Blanchard
In-Reply-To: <1180438885.19517.157.camel@localhost.localdomain>
On May 29, 2007, at 6:41 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 13:32 +0200, Christoph Hellwig wrote:
>> On Tue, May 29, 2007 at 04:45:23PM +1000, Benjamin Herrenschmidt
>> wrote:
>>> +static inline void check_syscall_restart(struct pt_regs *regs,
>>> + struct k_sigaction *ka,
>>> + int has_handler)
>>> +{
>>
>> I don't think this should be inlined. Just create a new signal.c
>> file,
>> which can grow a lot more common signal code later on aswell.
>
> I've been thinking about doing that too. In fact, some of the
> ptrace-common.h stuff should probably be turned back into ptrace.c too
> for the same reason. I'm still toying with that part of the designm
> but
> yeah, I think that's something to do.
I think this makes sense for the ptrace code as well. Eventually
we'll end up moving or supporting some of the 'features' that only
exist on one platform or the other in both. I can see us supporting
PTRACE_{GET,SET}_DEBUGREG on ppc32 and we'll need to support the
BOOKE stuff on ppc64.
- k
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Kumar Gala @ 2007-05-29 13:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070529064531.D874CDDF70@ozlabs.org>
On May 29, 2007, at 1:45 AM, Benjamin Herrenschmidt wrote:
> The powerpc ptrace code has some weirdness, like a ptrace-common.h
> file that
> is actually ppc64 only and some of the 32 bits code ifdef'ed inside
> ptrace.c.
>
> There are also separate implementations for things like get/
> set_vrregs for
> 32 and 64 bits which is totally unnecessary.
>
> This patch cleans that up a bit by having a ptrace-common.h which
> contains
> really common code (and makes a lot more code common), and ptrace-
> ppc32.h and
> ptrace-ppc64.h files that contain the few remaining different bits.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> arch/powerpc/kernel/ptrace-common.h | 89 +++++++---------
> arch/powerpc/kernel/ptrace-ppc32.h | 100 ++++++++++++++++++
> arch/powerpc/kernel/ptrace-ppc64.h | 51 +++++++++
> arch/powerpc/kernel/ptrace.c | 198
> ------------------------------------
> arch/powerpc/kernel/ptrace32.c | 1
> 5 files changed, 197 insertions(+), 242 deletions(-)
>
> Index: linux-cell/arch/powerpc/kernel/ptrace-common.h
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/ptrace-common.h 2007-05-29
> 13:05:55.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/ptrace-common.h 2007-05-29
> 16:22:00.000000000 +1000
> @@ -1,5 +1,6 @@
> /*
> * Copyright (c) 2002 Stephen Rothwell, IBM Coproration
> + * Copyright (c) 2007 Benjamin Herrenschmidt, IBM Coproration
> * Extracted from ptrace.c and ptrace32.c
> *
> * This file is subject to the terms and conditions of the GNU
> General
> @@ -7,15 +8,8 @@
> * this archive for more details.
> */
>
> -#ifndef _PPC64_PTRACE_COMMON_H
> -#define _PPC64_PTRACE_COMMON_H
> -
> -#include <asm/system.h>
> -
> -/*
> - * Set of msr bits that gdb can change on behalf of a process.
> - */
> -#define MSR_DEBUGCHANGE (MSR_FE0 | MSR_SE | MSR_BE | MSR_FE1)
> +#ifndef _POWERPC_PTRACE_COMMON_H
> +#define _POWERPC_PTRACE_COMMON_H
>
> /*
> * Get contents of register REGNO in task TASK.
> @@ -24,18 +18,18 @@ static inline unsigned long get_reg(stru
> {
> unsigned long tmp = 0;
>
> - /*
> - * Put the correct FP bits in, they might be wrong as a result
> - * of our lazy FP restore.
> - */
Do we do some different lazy save/restore on ppc64 than ppc32? I'm
trying to understand why the comment isn't (or wasn't) valid for
ppc32 as well.
> + if (task->thread.regs == NULL)
> + return -EIO;
> +
> if (regno == PT_MSR) {
> tmp = ((unsigned long *)task->thread.regs)[PT_MSR];
> - tmp |= task->thread.fpexc_mode;
> - } else if (regno < (sizeof(struct pt_regs) / sizeof(unsigned
> long))) {
> - tmp = ((unsigned long *)task->thread.regs)[regno];
> + return PT_MUNGE_MSR(tmp, task);
> }
>
> - return tmp;
> + if (regno < (sizeof(struct pt_regs) / sizeof(unsigned long)))
> + return ((unsigned long *)task->thread.regs)[regno];
> +
> + return -EIO;
> }
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Kumar Gala @ 2007-05-29 13:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <1180429370.19517.142.camel@localhost.localdomain>
On May 29, 2007, at 4:02 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 16:45 +1000, Benjamin Herrenschmidt wrote:
>>
>> This patch cleans that up a bit by having a ptrace-common.h which
>> contains
>> really common code (and makes a lot more code common), and
>> ptrace-ppc32.h and
>> ptrace-ppc64.h files that contain the few remaining different bits.
>
> Hrm.. we do have a subtle difference in vrregs that I've missed.. I'll
> respin tomorrow. It looks like we don't store the VRSAVE register
> at the
> same place on 32 and 64 bits... yuck. I need to double check tomorrow.
That's bad. We really should have VRSAVE in the same location for
both. (wondering if GDB expects it a different locations on 32 vs 64-
bits.)
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 13:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180431850.19517.146.camel@localhost.localdomain>
>> - how can an application know that it can use 64 bit registers and
>> call
>> the optimized routines?
>
> I'd say use the 32 bits ABI, AT_HWCAP will tell you if you are running
> on a 64 bits capable machine. You can then either use hand tuned code
> at
> runtime, or I think ld.so can load alternate libs based on the bits in
> there.
Or you can simply only install 64-bit binaries on 64-bit
machines.
>> Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or
>> 4.3 installed yet) that allows you to tell the compiler to use 32 bit
>> addresses but assume that integer registers are 64 bit wide. As long
>> as such an option does not exist, the usefulness of this feature is
>> somewhat limited. In other words, GCC for now has support for ILP32
>> and
>> LP64 modes, but it would be better to also have support for IP32L64.
>
> Depends... If such binaries are actual 64 bits binaries from a kernel
> POV, then no change is necessary.
The kernel (and some libraries that do explicit mmap()s)
will have to make sure that all pointers stay within the
32-bit address space. This is most easily done by only
allowing mappings in the low 32-bit, and some initial
memory layout work is needed I guess. Seems quite easy
actually, certainly from the kernel perspective. And the
gain is higher than that of -m32 -mpowerpc64 over -m32.
If you want to do the 32-bit ABI in 64-bit ELF binaries,
more work is involved. Might very well be even better
though.
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Kumar Gala @ 2007-05-29 13:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Anton Blanchard,
Paul Mackerras
In-Reply-To: <1180425900.19517.136.camel@localhost.localdomain>
On May 29, 2007, at 3:05 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 03:52 -0400, Dan Malek wrote:
>>> I've been looking at saving & restoring the top 32 bits of 64 bits
>>> registers when delivering signals to 32 bits processes on a 64 bits
>>> kernel. The principle is easy, but I wonder where to stick them.
>>
>> I'm wondering why you need to do this at all?
>> Why would a 32-bit application care about or
>> know what to do with these?
>
> There are regular demands for the ability to use the full 64 bits
> registers in 32 bits applications when running on a 64 bits processor.
> That ranges from, iirc, the java folks, to people wanting to optimize
> some libs to use 64 bits registers internally when called from 32 bits
> apps etc...
>
> You can use the full 64 bits easily on powerpc, ld/std just work, it's
> only the flags calculations and branches, mostly, that are truncated
> when running in 32 bits mode. Also, the kernel syscall & interrupt
> entry/exit path will save & restore the full 64 bits.
>
> The problem is when you use signals. The compat signal code for 32
> bits
> apps will only save and restore the bottom 32 bits, thus an
> application
> using signals will potentially corrupt the top 32 bits, which can be a
> problem if, for example, it uses a library that has optimisations
> based
> on using the full 64 bits.
>
> We don't intend to update jmpbuf, getcontext/setcontext etc... for
> those... they are purely call clobbered etc..., but it would be
> nice if
> at least the signal frame save/restore could properly deal with
> them so
> they don't get randomly clobbered.
This is all problematic since some 64-bit implementations may not
guarantee the upper bits are valid when in 32-bit mode. Look at the
'Computation Modes' section in the architecture specs 2.03 or greater
for embedded processors.
- k
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-29 13:04 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <20070529092658.GA32228@iram.es>
> But it also makes me wonder about a few things:
> - do you use the standard 32 bit ABI, in which case the caller of
> libraries
> does not care and the libraries can be put in the standard places,
The compiler should either a) use full 64-bit only for
"volatile" (call-clobbered) registers, or b) save and
restore other 64-bit mode registers around calls. I don't
remember if powerpc-linux-gcc does a) or b), if either.
> or are
> there cases where the ability to pass 64 bit values in a single
> register would improve performance to the point that it is worth
> having an incompatible library (where to put it and how to name it)?
That would be a third ABI. Is it worth that?
> - how can an application know that it can use 64 bit registers and call
> the optimized routines?
Just call them and trap the SEGV ;-) You can check the
aux vector of course, or ask glibc -- but the SEGV way
is the only really portable way. Strange world :-)
> Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or
> 4.3 installed yet) that allows you to tell the compiler to use 32 bit
> addresses but assume that integer registers are 64 bit wide.
This feature was developed in the 3.3 timeframe IIRC. The
flags to use are -m32 -mpowerpc64 .
> As long
> as such an option does not exist, the usefulness of this feature is
> somewhat limited. In other words, GCC for now has support for ILP32 and
> LP64 modes, but it would be better to also have support for IP32L64.
ILP32LL64. The C "mode" stays the same, only the generated
machine insns are changed.
> Adding the IP32L64 mode des not seem to be such a huge project
> (comparable to many Google SoC ones, but it's too late for 2007),
GCC (and many 3rd party apps/libs) *really* like pointers and
longs to have the same size.
> the problem is taht if it is started now, I don't think it will hit
> an official GCC release before 2009 at the earliest.
It has been there for a long time now ;-)
> Only the implicit flags calculations, cmp has both 32 and 64 bit
> versions, so it's not _that_ bad. However multiprecision arithmetic
> will
> have to be done in 32 bit mode
You actually want to do MP calc in 64-bit mode -- multiplies
are four times faster! (64x64 vs. 32x32).
> because the carry setting[1] is linked with the mode
True enough, but you never really need the CA reg anyway.
> (well I seem to remember a variant of the architecture
> which had 32 and 64 bit variants for generating the flags, but it was a
> long time ago. I've not seen support for this hybrid monster in gcc's
> md
> file and I don't know whether it ever saw the light).
Book E 64. You want to forget; well I want to anyway.
> Have you considered the case of a mixed (IP32L64) mode calling a pure
> 32 bit library (or a user provided callback). The high part of R13-R31
> will also be clobbered. Therefore the caller has to save and restore
> all registers that are live around the call, which results in
> significant code bloat and needs compiler support.
I believe the compiler supports this. The code bloat you
think is there just doesn't exist; it takes a lot more code
to do the actual ops on a pair of 32-bit regs than it takes
to do a bit of 64-bit save/restore work.
Segher
^ permalink raw reply
* Re: [PATCH] IB/ehca: Refactor "maybe missed event" code
From: Joachim Fenkes @ 2007-05-29 12:44 UTC (permalink / raw)
To: Roland Dreier
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <adalkfe6rxk.fsf@cisco.com>
Roland Dreier <rdreier@cisco.com> wrote on 24.05.2007 19:40:39:
> This isn't fixing anything is it? I think it's 2.6.23 material;
> correct me if I'm wrong.
Right, it doesn't fix things, just coalesces some code.
Joachim
^ permalink raw reply
* jffs2 and Amdflash
From: Nethra @ 2007-05-29 12:29 UTC (permalink / raw)
To: linuxppc-dev
hi.........
I m using custom board same as MPC8272ADS board.
u-boot is u-boot-1.1.2.
linux-2.6.10
Flash AM29LV641ML
no.of flash chips are 2
I have already tested jffs2 in 2 ways on MPC8272ADS board.......... =
=20
1) booted kernel with root as nfs and after that mounted jffs2 using comman=
d
mount -t jffs2 /dev/mtdblock0 /mnt
its working fine.
2) with root as jffs2....it is also working fine.
Now i m testing jffs2 on Custom board...
case 1 is working fine but 2nd is not working..
I have enabled DEBUG options in kernel so it is reading correctly as cfi
datas as per datasheet.
here is bootlog for Custom board...
bootlog for case 1
------------------------------------------------
physmap flash device: 1000000 at ff000000
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 =C2=B5s
Maximum byte/word write timeout: 256 =C2=B5s
Typical full buffer write timeout: 128 =C2=B5s
Maximum full buffer write timeout: 4096 =C2=B5s
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
cfip->DevSize=3D0x17
Device size: 0x800000 bytes (8 MiB)
Flash Device Interface description: 0x0001
- x16-only asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
Erase Region #0: BlockSize 0x10000 bytes, 128 blocks
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
Silicon revision: 4
Address sensitive unlock: Required
Erase Suspend: Read/write
Block protection: 4 sectors per group
Temporary block unprotect: Supported
Block protect/unprotect scheme: 4
Number of simultaneous operations: 0
Burst mode: Not supported
Page mode: 4 word page
Vpp Supply Minimum Program/Erase Voltage: 11.5 V
Vpp Supply Maximum Program/Erase Voltage: 12.5 V
Top/Bottom Boot Block: Uniform, Bottom WP
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
num_physmap_partitions=3D0x5
Using physmap partition definition
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "HRCW"
0x00040000-0x00e00000 : "User FS"
0x00e00000-0x00f00000 : "uImage"
0x00f00000-0x00f40000 : "bootloader"
0x00f40000-0x00f80000 : "bootloader env"
-------------------------------
bootlog for 2nd case..........
-----------------------------
physmap flash device: 1000000 at ff000000
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 =C2=B5s
Maximum byte/word write timeout: 256 =C2=B5s
Typical full buffer write timeout: 128 =C2=B5s
Maximum full buffer write timeout: 4096 =C2=B5s
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
cfip->DevSize=3D0x17
Device size: 0x800000 bytes (8 MiB)
Flash Device Interface description: 0x0001
- x16-only asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
Erase Region #0: BlockSize 0x10000 bytes, 128 blocks
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
Silicon revision: 4
Address sensitive unlock: Required
Erase Suspend: Read/write
Block protection: 4 sectors per group
Temporary block unprotect: Supported
Block protect/unprotect scheme: 4
Number of simultaneous operations: 0
Burst mode: Not supported
Page mode: 4 word page
Vpp Supply Minimum Program/Erase Voltage: 11.5 V
Vpp Supply Maximum Program/Erase Voltage: 12.5 V
Top/Bottom Boot Block: Uniform, Bottom WP
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
num_physmap_partitions=3D0x5
Using physmap partition definition
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "HRCW"
0x00040000-0x00e00000 : "User FS"
0x00e00000-0x00f00000 : "uImage"
0x00f00000-0x00f40000 : "bootloader"
0x00f40000-0x00f80000 : "bootloader env"
Empty flash at 0x004de47c ends at 0x004de480
Empty flash at 0x004de484 ends at 0x004de488
Empty flash at 0x004de4e4 ends at 0x004de4e8
Empty flash at 0x004de78c ends at 0x004de790
Empty flash at 0x004de794 ends at 0x004de798
Empty flash at 0x004de7f4 ends at 0x004de7f8
Empty flash at 0x004dea9c ends at 0x004deaa0
Empty flash at 0x004deaa4 ends at 0x004deaa8
Empty flash at 0x004deb04 ends at 0x004deb08
Empty flash at 0x004dedac ends at 0x004dedb0
Empty flash at 0x004dedb4 ends at 0x004dedb8
Empty flash at 0x004dee14 ends at 0x004dee18
Empty flash at 0x004df0bc ends at 0x004df0c0
Empty flash at 0x004df0c4 ends at 0x004df0c8
Empty flash at 0x004df124 ends at 0x004df128
Empty flash at 0x004df3cc ends at 0x004df3d0
Empty flash at 0x004df3d4 ends at 0x004df3d8
Empty flash at 0x004df434 ends at 0x004df438
Empty flash at 0x004df6dc ends at 0x004df6e0
Empty flash at 0x004df6e4 ends at 0x004df6e8
Empty flash at 0x004df744 ends at 0x004df748
Empty flash at 0x004df9ec ends at 0x004df9f0
Empty flash at 0x004df9f4 ends at 0x004df9f8
Empty flash at 0x004dfa54 ends at 0x004dfa58
Empty flash at 0x004dfcfc ends at 0x004dfd00
Empty flash at 0x004dfd04 ends at 0x004dfd08
Empty flash at 0x004dfd64 ends at 0x004dfd68
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 100k init
273c282, ino #51
rent (c0238dac)
right from frag 225280-229376, before the region we care about
ght (c0238ad4), parent (c0238c24)
8). left (c3d9e540), right (c3d9e658), parent (c3d9e578)
: hole (*c0238f34). left (c0238f6c} right (c0238f50), parent (c3d9d2d8)
: 0x00019464(2) on flash (*c0238ec4). left (c0238d74), right (c0238e54),
parent (c0238f88)
3873224, checked_ino #37
001a
what is the error...can anybody help me..?
thanks in advance
nethra
--=20
View this message in context: http://www.nabble.com/jffs2-and-Amdflash-tf38=
33576.html#a10853134
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] powerpc: remove unused do_signal export
From: Christoph Hellwig @ 2007-05-29 11:49 UTC (permalink / raw)
To: linuxppc-dev
do_signal is never used in modular code (obviously), and not other
architecture exports it either.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/ppc_ksyms.c 2007-05-29 12:34:22.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/ppc_ksyms.c 2007-05-29 12:34:30.000000000 +0200
@@ -67,7 +67,6 @@ EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
-EXPORT_SYMBOL(do_signal);
EXPORT_SYMBOL(transfer_to_handler);
EXPORT_SYMBOL(do_IRQ);
EXPORT_SYMBOL(machine_check_exception);
Index: linux-2.6/arch/powerpc/kernel/signal_64.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/signal_64.c 2007-05-29 12:34:46.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/signal_64.c 2007-05-29 12:34:54.000000000 +0200
@@ -568,4 +568,3 @@ int do_signal(sigset_t *oldset, struct p
return 0;
}
-EXPORT_SYMBOL(do_signal);
Index: linux-2.6/arch/ppc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.orig/arch/ppc/kernel/ppc_ksyms.c 2007-05-29 12:34:38.000000000 +0200
+++ linux-2.6/arch/ppc/kernel/ppc_ksyms.c 2007-05-29 12:34:41.000000000 +0200
@@ -65,7 +65,6 @@ extern unsigned long mm_ptov (unsigned l
EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(clear_user_page);
-EXPORT_SYMBOL(do_signal);
EXPORT_SYMBOL(transfer_to_handler);
EXPORT_SYMBOL(do_IRQ);
EXPORT_SYMBOL(machine_check_exception);
^ 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