* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 18:58 UTC (permalink / raw)
To: Grant Likely, Josh Boyer; +Cc: linuxppc-dev, hollisb, Tirumala Reddy Marri
In-Reply-To: <fa686aa40904171157x207d6493v9a37e2d8c61113d3@mail.gmail.com>
Thanks everyone, will do.
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Friday, April 17, 2009 12:58 PM
> To: Josh Boyer
> Cc: John Linn; Tirumala Reddy Marri; linuxppc-dev@ozlabs.org; hollisb@us.=
ibm.com
> Subject: Re: Question about DBCR0 initialization for 440
> =
> Hey John
> =
> We just discussed this on IRC. Go ahead and generate a patch to
> unconditionally turn on DBCR0[IDM] in head_44x.S. Don't even bother
> wrapping it in an #ifdef CONFIG_somthing block. It should be safe,
> but we'll throw it into -next and see if anyone complains. If it does
> cause problems, then it can be reworked to something a wee bit more
> conservative.
> =
> g.
> =
> On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com>=
wrote:
> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrot=
e:
> >> Josh, any thoughts on putting this into head_44x.S?
> >
> > The code in the fsl file looks like the right solution. =A0I do have an=
> > odd question though, in that it's hard for the
> > kernel to really know if something like a BDI is running. =A0Namely,
> > that config option doesn't cover RiscWatch in an obvious manner.
> >
> > I also wonder if it's possible to have a host system be setting those
> > registers in a guest KVM system so the guest could be debugged with
> > gdb... =A0Hollis, any idea on that?
> >
> > josh
> >
> =
> =
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Grant Likely @ 2009-04-17 19:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, John Linn, Hollis Blanchard, Tirumala Reddy Marri
In-Reply-To: <1239995087.7210.19.camel@pasglop>
On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
>> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
>> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wro=
te:
>> > > Josh, any thoughts on putting this into head_44x.S?
>> >
>> > The code in the fsl file looks like the right solution. =A0I do have a=
n
>> > odd question though, in that it's hard for the
>> > kernel to really know if something like a BDI is running. =A0Namely,
>> > that config option doesn't cover RiscWatch in an obvious manner.
>>
>> Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef mean=
ds you
>> can't support both a JTAG debugger and hardware breakpoints in the same
>> binary? Now that's an annoying restriction.
>
> Might be worth checking if external debug is enabled, and override it
> only if it's not.
ppc440x5_um.pdf says that both can be enabled.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Benjamin Herrenschmidt @ 2009-04-17 19:04 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, John Linn, Tirumala Reddy Marri
In-Reply-To: <200904171307.47734.hollisb@us.ibm.com>
On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> > > Josh, any thoughts on putting this into head_44x.S?
> >
> > The code in the fsl file looks like the right solution. I do have an
> > odd question though, in that it's hard for the
> > kernel to really know if something like a BDI is running. Namely,
> > that config option doesn't cover RiscWatch in an obvious manner.
>
> Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you
> can't support both a JTAG debugger and hardware breakpoints in the same
> binary? Now that's an annoying restriction.
Might be worth checking if external debug is enabled, and override it
only if it's not.
Ben.
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Grant Likely @ 2009-04-17 18:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, John Linn, hollisb, Tirumala Reddy Marri
In-Reply-To: <625fc13d0904171022u4d7d5d8cve0ccfb74cc31f554@mail.gmail.com>
Hey John
We just discussed this on IRC. Go ahead and generate a patch to
unconditionally turn on DBCR0[IDM] in head_44x.S. Don't even bother
wrapping it in an #ifdef CONFIG_somthing block. It should be safe,
but we'll throw it into -next and see if anyone complains. If it does
cause problems, then it can be reworked to something a wee bit more
conservative.
g.
On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> w=
rote:
> On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
>> Josh, any thoughts on putting this into head_44x.S?
>
> The code in the fsl file looks like the right solution. =A0I do have an
> odd question though, in that it's hard for the
> kernel to really know if something like a BDI is running. =A0Namely,
> that config option doesn't cover RiscWatch in an obvious manner.
>
> I also wonder if it's possible to have a host system be setting those
> registers in a guest KVM system so the guest could be debugged with
> gdb... =A0Hollis, any idea on that?
>
> josh
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Anton Vorontsov @ 2009-04-17 18:23 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linuxppc-dev, Roderick Colenbrander, linux-ide
In-Reply-To: <200904172017.18486.bzolnier@gmail.com>
On Fri, Apr 17, 2009 at 08:17:18PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday 17 April 2009 18:49:44 Benjamin Herrenschmidt wrote:
> > > But they don't. On MPC8610HPCD we have IDE interrupt directly
> > > connected to the MPIC line (through PCI sideband interrupt), and
> > > i8259 is _completely_ disabled in the bridge.
> >
> > Hrm why did you do that ? :-)
> >
> > Just kidding... if what you want is the PCI interrupt, then it should
> > be in native mode, not legacy mode... Maybe the driver can figure out
> > how the chip is configured by reading said configuration and use
> > either the legacy interrupts or the PCI one...
> >
> > > See this commit:
> > >
> > > commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
> > > Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> > > Date: Tue Apr 29 22:57:38 2008 +0200
> > >
> > > alim15x3: disable init_hwif_ali15x3 for PowerPC
> > >
> > > > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > >
> > > If the patch applied, MPC8610HPCD will be broken.
> > >
> > > We need at least some machine_is() check.
> >
> > That sucks. That's an endless problems with IDE and those on-board
> > chipsets though. The interrupts should pretty much -always- be provided
> > by the arch code, but for some reason, that got removed in favor of
> > various hacks in the drivers themselves...
>
> Previous PPC IRQ hacks combined with IDE IRQ hacks were a real nightmare
> from maintenance perspective -- one could just never tell what is going
> on and whether it is correct.
>
> IDE host driver specific hacks were just a necessary temporary step into
> solving this problem and most of them got removed in this merge window
> during more general rework of IRQ setup code.
>
> Nowadays IDE PCI layer just consistently uses arch specific (+ non-IDE
> specific so libata gets benefits too) pci_get_legacy_ide_irq() helper
> for legacy IRQs, please see ide_pci_init_one():
>
> ...
> /* fixup IRQ */
> if (ide_pci_is_in_compatibility_mode(dev)) {
> hw[0].irq = pci_get_legacy_ide_irq(dev, 0);
> hw[1].irq = pci_get_legacy_ide_irq(dev, 1);
> } else
> hw[1].irq = hw[0].irq = ret;
> ...
>
> That's all! No PPC-specific IRQ overrides, IDE-specific IRQ overrides
> and IDE host driver ones needed! :)
>
> There is still some legacy code (like the one in alim15x3 host driver)
> needing fixing but the infrastructure allowing it should be all there.
>
> Hmm, it looks like this historical IRQ override in init_hwif_ali15x3():
>
> if (dev->device == PCI_DEVICE_ID_AL_M5229)
> hwif->irq = hwif->channel ? 15 : 14;
>
> should be just removed nowadays.
>
> Seems like this should allow MPC8610HPCD to work with Roderick's patch
> if the IDE controller is set to native mode and ALI south-bridge SIRQ
> tables are correctly set (or if this is not ALI's south-bridge). Anton?
OK, I'll test this approach.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: ppc32 needs elf_read_implies_exec()
From: Kumar Gala @ 2009-04-17 18:16 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Alan Modra
Cc: Linuxppc-dev Development
In-Reply-To: <1239991381-11649-1-git-send-email-galak@kernel.crashing.org>
On Apr 17, 2009, at 1:03 PM, Kumar Gala wrote:
> On ppc64 we implemented elf_read_implies_exec() for 32-bit binaries
> because old toolchains had bugs with regards to marking PHDRs as
> executable that needed to be. For some reason we didn't do this on
> ppc32 builds. This hadn't been an issue until recent changes to I$/D$
> handling that impacted the per-page exec handling on embedded PPC.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/elf.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/
> asm/elf.h
> index 1a856b1..b6ada56 100644
> --- a/arch/powerpc/include/asm/elf.h
> +++ b/arch/powerpc/include/asm/elf.h
> @@ -259,6 +259,7 @@ do { \
> (exec_stk != EXSTACK_DISABLE_X) : 0)
> #else
> # define SET_PERSONALITY(ex) set_personality(PER_LINUX)
> +# define elf_read_implies_exec(ex, exec_stk) (exec_stk !=
> EXSTACK_DISABLE_X)
> #endif /* __powerpc64__ */
>
> extern int dcache_bsize;
> --
> 1.6.0.6
I just want to make sure I understand the implications of this
change. It seems to me that we will not be able to support stack exec
perms on any ppc32 part that has per-page exec support. Is that correct?
I'm wondering if we are too generous in the check, exec_stk can be:
EXSTACK_DEFAULT
EXSTACK_DISABLE_X
EXSTACK_ENABLE_X
It seems like EXSTACK_DISABLE_X/EXSTACK_ENABLE_X are only set if
p_type == PT_GNU_STACK. Do we think toolchains existed that set
p_type to PT_GNU_STACK that don't set PF_X properly?
My thinking is elf_read_implies_exec() should be changed to:
# define elf_read_implies_exec(ex, exec_stk) (exec_stk ==
EXSTACK_DEFAULT)
- k
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Bartlomiej Zolnierkiewicz @ 2009-04-17 18:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ide, Roderick Colenbrander, linuxppc-dev
In-Reply-To: <1239986984.7210.9.camel@pasglop>
On Friday 17 April 2009 18:49:44 Benjamin Herrenschmidt wrote:
> > But they don't. On MPC8610HPCD we have IDE interrupt directly
> > connected to the MPIC line (through PCI sideband interrupt), and
> > i8259 is _completely_ disabled in the bridge.
>
> Hrm why did you do that ? :-)
>
> Just kidding... if what you want is the PCI interrupt, then it should
> be in native mode, not legacy mode... Maybe the driver can figure out
> how the chip is configured by reading said configuration and use
> either the legacy interrupts or the PCI one...
>
> > See this commit:
> >
> > commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
> > Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Date: Tue Apr 29 22:57:38 2008 +0200
> >
> > alim15x3: disable init_hwif_ali15x3 for PowerPC
> >
> > > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > If the patch applied, MPC8610HPCD will be broken.
> >
> > We need at least some machine_is() check.
>
> That sucks. That's an endless problems with IDE and those on-board
> chipsets though. The interrupts should pretty much -always- be provided
> by the arch code, but for some reason, that got removed in favor of
> various hacks in the drivers themselves...
Previous PPC IRQ hacks combined with IDE IRQ hacks were a real nightmare
from maintenance perspective -- one could just never tell what is going
on and whether it is correct.
IDE host driver specific hacks were just a necessary temporary step into
solving this problem and most of them got removed in this merge window
during more general rework of IRQ setup code.
Nowadays IDE PCI layer just consistently uses arch specific (+ non-IDE
specific so libata gets benefits too) pci_get_legacy_ide_irq() helper
for legacy IRQs, please see ide_pci_init_one():
...
/* fixup IRQ */
if (ide_pci_is_in_compatibility_mode(dev)) {
hw[0].irq = pci_get_legacy_ide_irq(dev, 0);
hw[1].irq = pci_get_legacy_ide_irq(dev, 1);
} else
hw[1].irq = hw[0].irq = ret;
...
That's all! No PPC-specific IRQ overrides, IDE-specific IRQ overrides
and IDE host driver ones needed! :)
There is still some legacy code (like the one in alim15x3 host driver)
needing fixing but the infrastructure allowing it should be all there.
Hmm, it looks like this historical IRQ override in init_hwif_ali15x3():
if (dev->device == PCI_DEVICE_ID_AL_M5229)
hwif->irq = hwif->channel ? 15 : 14;
should be just removed nowadays.
Seems like this should allow MPC8610HPCD to work with Roderick's patch
if the IDE controller is set to native mode and ALI south-bridge SIRQ
tables are correctly set (or if this is not ALI's south-bridge). Anton?
Thanks,
Bart
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Hollis Blanchard @ 2009-04-17 18:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, John Linn, Tirumala Reddy Marri
In-Reply-To: <625fc13d0904171022u4d7d5d8cve0ccfb74cc31f554@mail.gmail.com>
On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> > Josh, any thoughts on putting this into head_44x.S?
>
> The code in the fsl file looks like the right solution. I do have an
> odd question though, in that it's hard for the
> kernel to really know if something like a BDI is running. Namely,
> that config option doesn't cover RiscWatch in an obvious manner.
Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you
can't support both a JTAG debugger and hardware breakpoints in the same
binary? Now that's an annoying restriction.
> I also wonder if it's possible to have a host system be setting those
> registers in a guest KVM system so the guest could be debugged with
> gdb... Hollis, any idea on that?
You mean is KVM currently doing that, and would this patch conflict with that
behavior?
Right now KVM (on 440) context switches the necessary DB* registers for out-
of-band debugging. That is, qemu sends a "set breakpoint in guest" ioctl to
KVM, and then when switching from host to guest mode, KVM will save the old
DB* values, put in some new ones, and swap them back again when re-entering
the host. So I *think* the answer to your question is "yes, KVM messes with
these registers to enable software breakpoints when debugging a guest with
gdb." That code path isn't heavily tested, but the values put into DB* by
other host code shouldn't matter.
However, KVM doesn't support in-band breakpoints, i.e. it doesn't emulate the
setting of those registers from within the guest. It's basically a no-op. So
whether the kernel sets them or not, in-band debugging won't work with the
current KVM code.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] powerpc: ppc32 needs elf_read_implies_exec()
From: Kumar Gala @ 2009-04-17 18:03 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, Benjamin Herrenschmidt
On ppc64 we implemented elf_read_implies_exec() for 32-bit binaries
because old toolchains had bugs with regards to marking PHDRs as
executable that needed to be. For some reason we didn't do this on
ppc32 builds. This hadn't been an issue until recent changes to I$/D$
handling that impacted the per-page exec handling on embedded PPC.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/elf.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 1a856b1..b6ada56 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -259,6 +259,7 @@ do { \
(exec_stk != EXSTACK_DISABLE_X) : 0)
#else
# define SET_PERSONALITY(ex) set_personality(PER_LINUX)
+# define elf_read_implies_exec(ex, exec_stk) (exec_stk != EXSTACK_DISABLE_X)
#endif /* __powerpc64__ */
extern int dcache_bsize;
--
1.6.0.6
^ permalink raw reply related
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 17:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <1599F61A-ADDE-4846-B3A9-263918995618@kernel.crashing.org>
On Fri, 2009-04-17 at 12:40 -0500, Kumar Gala wrote:
> > 1- In binfmt_elf.c, what happens with this statement ?
> >
> > if (elf_read_implies_exec(loc->elf_ex, executable_stack))
> > current->personality |= READ_IMPLIES_EXEC;
>
> on ppc32 noting as its elf_read_implies_exec is not implemented.
>
Right, I got confused, somewhat assumed you were on BookE 64-bit or
something :-) We just need to make 32-bit do the same as 64-bit for now
and that should do the trick.
Ben.
^ permalink raw reply
* Re: issues w/init
From: Kumar Gala @ 2009-04-17 17:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <1239987791.7210.15.camel@pasglop>
On Apr 17, 2009, at 12:03 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 08:23 -0500, Kumar Gala wrote:
>> I can and might have already done this, need to double check. But
>> what I was seeing from elf_map is that we don't get PROT_EXEC set for
>> this PHDR, but get VM_MAY_EXEC. I'm not clear on what VM_MAY_EXEC is
>> intended for.
>
> Looking at a 2.6.29 tree here, I don't see any reference to
> VM_MAY_EXEC
> but I see a VM_MAYEXEC :-) Though it shouldn't be relevant here.
>
> What I see, and what should be checked is:
>
> 1- In binfmt_elf.c, what happens with this statement ?
>
> if (elf_read_implies_exec(loc->elf_ex, executable_stack))
> current->personality |= READ_IMPLIES_EXEC;
on ppc32 noting as its elf_read_implies_exec is not implemented.
> (ie. is the personality flag set ?)
>
> 2- When the phdr's are mmap'ed, do you hit this:
>
> if ((prot & PROT_READ) && (current->personality &
> READ_IMPLIES_EXEC))
> if (!(file && (file->f_path.mnt->mnt_flags &
> MNT_NOEXEC)))
> prot |= PROT_EXEC;
>
> (Which should later be turned into VM_EXEC by calc_vm_prot_bits().
>
> If any of these isn't happening, then we need to figure out why.
As I said before current->personality = 0 in ppc32 in the setup I've
got. (because we don't have elf_read_implies_exec defined). I can
define it and doing so makes this all work properly. I'm just
questioning if defining elf_read_implies_exec for ppc32 is actually
the right answer or not.
- k
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Kumar Gala @ 2009-04-17 17:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development, Roderick Colenbrander
In-Reply-To: <1239987912.7210.17.camel@pasglop>
On Apr 17, 2009, at 12:05 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 09:08 -0500, Kumar Gala wrote:
>> The problem is that the "normal" PCI config access routines need a
>> pci_bus. However we don't have one yet and we need to do PCI config
>> cycles to the PHB before we call the remainder of the setup code to
>> get one.
>>
>> We could all call our own ops directly and provide a fake bus but
>> this
>> is pretty much what the early routines do for us in a common way.
>
> Ah right, slipped out of my mind. Oh well, easy to make the code
> common, move it to pci-common.c
Right, I can do that... In doing so I was wondering two things w/
regards to fake_pci_bus:
1. can we drop the hose == 0 check, it looks like there are 3 users of
the early pci ops code (fsl, 4xx, pmac). The FSL one I can say passes
a valid hose in and it looks like 4xx does as well. The pmac code is
always a bit more trick so I figured you might know
2. Do we believe those hose->ops is always valid -- again FSL & 4xx it
is, pmac??
static struct pci_bus *
fake_pci_bus(struct pci_controller *hose, int busnr)
{
static struct pci_bus bus;
if (hose == 0) {
hose = pci_bus_to_hose(busnr);
if (hose == 0)
printk(KERN_ERR "Can't find hose for PCI bus
%d!\n", busnr);
}
bus.number = busnr;
bus.sysdata = hose;
bus.ops = hose? hose->ops: &null_pci_ops;
return &bus;
}
^ permalink raw reply
* ELDK / U-Boot on the Emerson Network Power mvme5100
From: Kirby Cartwright @ 2009-04-17 17:08 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1.1: Type: text/plain, Size: 447 bytes --]
Does anyone know of a BSP or board directory or configuration for the Embedded Linux Development Kit (ELDK) and especially U-Boot on the mvme5100?
I have searched the ELDK and LinuxPPC mailing lists and have not found anything yet.
Cross posted to the ELDK mailing list.
Thanks in advance for your help,
Kirby W. Cartwright
Sr. Software Engineer
Star Dynamics Corporation
614-540-8227
[cid:image001.jpg@01C9BF5D.AAF29C60]
[-- Attachment #1.2: Type: text/html, Size: 4100 bytes --]
[-- Attachment #2: image001.jpg --]
[-- Type: image/jpeg, Size: 2163 bytes --]
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Josh Boyer @ 2009-04-17 17:22 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev, hollisb, Tirumala Reddy Marri
In-Reply-To: <20090417154628.43F859D0055@mail178-wa4.bigfish.com>
On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrote:
> Josh, any thoughts on putting this into head_44x.S?
The code in the fsl file looks like the right solution. I do have an
odd question though, in that it's hard for the
kernel to really know if something like a BDI is running. Namely,
that config option doesn't cover RiscWatch in an obvious manner.
I also wonder if it's possible to have a host system be setting those
registers in a guest KVM system so the guest could be debugged with
gdb... Hollis, any idea on that?
josh
^ permalink raw reply
* Re: Example dts file
From: Grant Likely @ 2009-04-17 17:12 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49E8B69A.8010005@embeddedarm.com>
On Fri, Apr 17, 2009 at 11:04 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
> Hello,
>
> I'm working on creating a dts file for a custom board based on the Yosemite
> AMCC 440EP evaluation board. We have an FPGA connected to the PCI bus, and
> I'm a bit unsure how to describe this in the dts file. The FPGA implements
> an SD card core, RTC core, Nand core... Can anyone point me to an example
> dts file I can refer to?
If it is attached to the PCI bus, then you don't need to describe it
in the .dts file. PCI can reliably probe for devices. Your driver
should know what devices are present based on the PCI vendor and
device IDs.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 17:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <B6C2A84E-7481-47D3-A85A-C2D8218354A4@kernel.crashing.org>
> On ppc32 personality is clearly set to 0. On ppc64 the
> elf_read_implies_exec does work around the issue (ie I implemented
> elf_read_implies_exec as (exec_stk != EXSTACK_DISABLE_X) on ppc32).
> However I think its just masking it.
How so ? IE, it checks for PT_GNU_STACK, if not present, it then
sets read to imply exec. Things compiled with a fixed toolchain
have that no ?
Ben.
> Hear are the PHDRs for the version of init I'm running:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
> Align
> PHDR 0x000034 0x10000034 0x10000034 0x000e0 0x000e0 R E 0x4
> INTERP 0x000114 0x10000114 0x10000114 0x0000d 0x0000d R 0x1
> [Requesting program interpreter: /lib/ld.so.1]
> LOAD 0x000000 0x10000000 0x10000000 0x072a0 0x072a0 R E
> 0x10000
> LOAD 0x0072a0 0x100172a0 0x100172a0 0x00358 0x00988 RW
> 0x10000
> DYNAMIC 0x0074bc 0x100174bc 0x100174bc 0x000c8 0x000c8 RW 0x4
> NOTE 0x000130 0x10000130 0x10000130 0x00020 0x00020 R
> 0x10
>
> I don't think elf_read_implies_exec() is the right solution on ppc32.
> As I asked before, can VM_MAYEXEC be of any use to us?
>
> - k
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 17:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <087C29B1-39CA-4A32-81E6-533FAD21A2BC@kernel.crashing.org>
On Fri, 2009-04-17 at 08:23 -0500, Kumar Gala wrote:
> I can and might have already done this, need to double check. But
> what I was seeing from elf_map is that we don't get PROT_EXEC set for
> this PHDR, but get VM_MAY_EXEC. I'm not clear on what VM_MAY_EXEC is
> intended for.
Looking at a 2.6.29 tree here, I don't see any reference to VM_MAY_EXEC
but I see a VM_MAYEXEC :-) Though it shouldn't be relevant here.
What I see, and what should be checked is:
1- In binfmt_elf.c, what happens with this statement ?
if (elf_read_implies_exec(loc->elf_ex, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
(ie. is the personality flag set ?)
2- When the phdr's are mmap'ed, do you hit this:
if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
if (!(file && (file->f_path.mnt->mnt_flags & MNT_NOEXEC)))
prot |= PROT_EXEC;
(Which should later be turned into VM_EXEC by calc_vm_prot_bits().
If any of these isn't happening, then we need to figure out why.
Cheers,
Ben.
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Benjamin Herrenschmidt @ 2009-04-17 17:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Roderick Colenbrander
In-Reply-To: <5A611DAC-A7E2-4E96-A087-B9BFD8DF59F9@kernel.crashing.org>
On Fri, 2009-04-17 at 09:08 -0500, Kumar Gala wrote:
> The problem is that the "normal" PCI config access routines need a
> pci_bus. However we don't have one yet and we need to do PCI config
> cycles to the PHB before we call the remainder of the setup code to
> get one.
>
> We could all call our own ops directly and provide a fake bus but
> this
> is pretty much what the early routines do for us in a common way.
Ah right, slipped out of my mind. Oh well, easy to make the code
common, move it to pci-common.c
Cheers,
Ben.
^ permalink raw reply
* Example dts file
From: Eddie Dawydiuk @ 2009-04-17 17:04 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
Hello,
I'm working on creating a dts file for a custom board based on the Yosemite AMCC
440EP evaluation board. We have an FPGA connected to the PCI bus, and I'm a bit
unsure how to describe this in the dts file. The FPGA implements an SD card
core, RTC core, Nand core... Can anyone point me to an example dts file I can
refer to?
I've read that I'm not required to describe every PCI device in the system.
Although I'd like to eventually submit our changes for upstream support, so as
far as I know I do need to specify all of these devices in the dts file, so
drivers can parse the dts file to know what devices are present.
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Benjamin Herrenschmidt @ 2009-04-17 16:49 UTC (permalink / raw)
To: avorontsov
Cc: linux-ide, Roderick Colenbrander, Bartlomiej Zolnierkiewicz,
linuxppc-dev
In-Reply-To: <20090417124014.GA8944@oksana.dev.rtsoft.ru>
> But they don't. On MPC8610HPCD we have IDE interrupt directly
> connected to the MPIC line (through PCI sideband interrupt), and
> i8259 is _completely_ disabled in the bridge.
Hrm why did you do that ? :-)
Just kidding... if what you want is the PCI interrupt, then it should
be in native mode, not legacy mode... Maybe the driver can figure out
how the chip is configured by reading said configuration and use
either the legacy interrupts or the PCI one...
> See this commit:
>
> commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date: Tue Apr 29 22:57:38 2008 +0200
>
> alim15x3: disable init_hwif_ali15x3 for PowerPC
>
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> If the patch applied, MPC8610HPCD will be broken.
>
> We need at least some machine_is() check.
That sucks. That's an endless problems with IDE and those on-board
chipsets though. The interrupts should pretty much -always- be provided
by the arch code, but for some reason, that got removed in favor of
various hacks in the drivers themselves...
Ben.
> > > > Regards,
> > > > Roderick Colenbrander
> > > >
> > > >
> > > > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
> > > > From: Roderick Colenbrander <thunderbird2k@gmail.com>
> > > > Date: Wed, 15 Apr 2009 10:45:17 +0200
> > > > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
> > > > x86-like PowerPC boards like Xilinx ML310/410/510.
> > >
> > > Roderick, please add your "Signed-off-by:" line
> > > (per Documentation/SubmittingPatches).
> > >
> > > Thanks.
> > >
> > > > ---
> > > > drivers/ide/alim15x3.c | 9 +++++----
> > > > 1 files changed, 5 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
> > > > index 537da1c..9176c0f 100644
> > > > --- a/drivers/ide/alim15x3.c
> > > > +++ b/drivers/ide/alim15x3.c
> > > > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
> > > > return cbl;
> > > > }
> > > >
> > > > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> > > > +#if !defined(CONFIG_SPARC64)
> > > > /**
> > > > * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
> > > > * @hwif: interface to configure
> > > > *
> > > > * Obtain the IRQ tables for an ALi based IDE solution on the PC
> > > > - * class platforms. This part of the code isn't applicable to the
> > > > - * Sparc and PowerPC systems.
> > > > + * class platforms. This part of the code isn't applicable to
> > > > + * Sparc systems. It is usable on 'x86-like' PowerPC systems
> > > > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510.
> > > > */
> > > >
> > > > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > > > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > > > }
> > > > #else
> > > > #define init_hwif_ali15x3 NULL
> > > > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
> > > > +#endif /* !defined(CONFIG_SPARC64) */
> > > >
> > > > /**
> > > > * init_dma_ali15x3 - set up DMA on ALi15x3
> > > > --
> > > > 1.5.6.3
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* [patch] powerpc/pasemi: Fix no SMP build error
From: Geoff Levand @ 2009-04-17 16:36 UTC (permalink / raw)
To: Paul Mackerras
Cc: sachinp, Stephen Rothwell, linux-kernel, Linuxppc-dev, linux-next,
Olof Johansson, subrata
In-Reply-To: <1239285094.5188.65.camel@subratamodak.linux.ibm.com>
A non-SMP version of smp_send_stop() is now included in smp.h.
Remove the unneeded def in the pasemi setup.c.
Fixes build errors like these when CONFIG_SMP=3Dn:
arch/powerpc/platforms/pasemi/setup.c:48: error: redefinition of =E2=80=
=98smp_send_stop=E2=80=99
include/linux/smp.h:125: error: previous definition of 'smp_send_stop' =
was here
Reported-by: subrata@linux.vnet.ibm.com
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platfor=
ms/pasemi/setup.c
index c64fb5b..153051e 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -44,10 +44,6 @@
=20
#include "pasemi.h"
=20
-#if !defined(CONFIG_SMP)
-static void smp_send_stop(void) {}
-#endif
-
/* SDC reset register, must be pre-mapped at reset time */
static void __iomem *reset_reg;
=20
^ permalink raw reply related
* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 15:46 UTC (permalink / raw)
To: Tirumala Reddy Marri, jwboyer, grant.likely, linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C0729E57E@SDCEXCHANGE01.ad.amcc.com>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
Josh, any thoughts on putting this into head_44x.S?
Thanks,
John
________________________________
From: linuxppc-dev-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+john.linn=xilinx.com@ozlabs.org] On Behalf
Of Tirumala Reddy Marri
Sent: Wednesday, April 15, 2009 10:24 AM
To: John Linn; jwboyer@linux.vnet.ibm.com; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org
Subject: RE: Question about DBCR0 initialization for 440
Some debuggers like BDI(Abatron) they setup the debug registers. If you
have different debugger which doesn't support configuring debug
registers I suggest you to program then in the head_44x.S file.
From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
John Linn
Sent: Tuesday, April 14, 2009 1:33 PM
To: jwboyer@linux.vnet.ibm.com; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org
Subject: Question about DBCR0 initialization for 440
The kernel does not initialize the PPC440 DBCR0 register. This prevents
(among other things) the use of software breakpoints with GDB. I
realize that boot loaders probably do initialize this but we run a lot
without a boot loader and so do our customers.
The file, head_fsl_booke.S, does initialize the register for the
freescale specific code (as shown at the end of the message).
We are needing this also for Xilinx. What's the best method to
incorporate this, is it possible to add to head_44x.S?
Thanks,
John
#if !defined(CONFIG_BDI_SWITCH)
/*
* The Abatron BDI JTAG debugger does not tolerate others
* mucking with the debug registers.
*/
lis r2,DBCR0_IDM@h
mtspr SPRN_DBCR0,r2
isync
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
#endif
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are
not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 13645 bytes --]
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Kumar Gala @ 2009-04-17 14:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development, Roderick Colenbrander
In-Reply-To: <1239957182.7443.58.camel@pasglop>
On Apr 17, 2009, at 3:33 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 10:03 +0200, Roderick Colenbrander wrote:
>>
>> There are cases when it is really needed (or you would have to access
>> the address and data bus by hand). In my case I'm using a Xilinx PLB
>> soft-core and if certain options in the configuration header aren't
>> set (which aren't set by default) the soft-core is basically
>> disabled.
>> Cases like this look like valid cases in which early config should be
>> used.
>
> I still wonder whether we could just setup the pci_controller data
> structure and use "normal" PCI config access routines...
The problem is that the "normal" PCI config access routines need a
pci_bus. However we don't have one yet and we need to do PCI config
cycles to the PHB before we call the remainder of the setup code to
get one.
We could all call our own ops directly and provide a fake bus but this
is pretty much what the early routines do for us in a common way.
- k
^ permalink raw reply
* Re: issues w/init
From: Kumar Gala @ 2009-04-17 13:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <1239964860.7443.65.camel@pasglop>
On Apr 17, 2009, at 5:41 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 20:05 +1000, Paul Mackerras wrote:
>> Benjamin Herrenschmidt writes:
>>
>>> I'm pretty sure they are broken already when running off a 64-bit
>>> kernel,
>>
>> Maybe not... for 64-bit kernels we have our definition of
>> elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
>> sets the read-implies-exec personality thing on old 32-bit binaries.
>
> Ok, so looking at that more closely, if that had worked, we would
> have had PROT_EXEC, and thus VM_EXEC added to the vma by mmap... which
> apparently didn't occur.
>
> I think what may be happening is that the binary he's running has the
> PT_GNU_STACK but his libc doesn't ... the kernel will set the
> personality flag based on the binary you are trying to run, not any
> library it uses...
>
> Kumar, can you try to instrument that a bit and tell us ? What the
> personality flag gets set to and whether mmap sets PROT_EXEC ?
On ppc32 personality is clearly set to 0. On ppc64 the
elf_read_implies_exec does work around the issue (ie I implemented
elf_read_implies_exec as (exec_stk != EXSTACK_DISABLE_X) on ppc32).
However I think its just masking it.
Hear are the PHDRs for the version of init I'm running:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Align
PHDR 0x000034 0x10000034 0x10000034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x10000114 0x10000114 0x0000d 0x0000d R 0x1
[Requesting program interpreter: /lib/ld.so.1]
LOAD 0x000000 0x10000000 0x10000000 0x072a0 0x072a0 R E
0x10000
LOAD 0x0072a0 0x100172a0 0x100172a0 0x00358 0x00988 RW
0x10000
DYNAMIC 0x0074bc 0x100174bc 0x100174bc 0x000c8 0x000c8 RW 0x4
NOTE 0x000130 0x10000130 0x10000130 0x00020 0x00020 R
0x10
I don't think elf_read_implies_exec() is the right solution on ppc32.
As I asked before, can VM_MAYEXEC be of any use to us?
- k
^ permalink raw reply
* Re: issues w/init
From: Kumar Gala @ 2009-04-17 13:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <1239964860.7443.65.camel@pasglop>
On Apr 17, 2009, at 5:41 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 20:05 +1000, Paul Mackerras wrote:
>> Benjamin Herrenschmidt writes:
>>
>>> I'm pretty sure they are broken already when running off a 64-bit
>>> kernel,
>>
>> Maybe not... for 64-bit kernels we have our definition of
>> elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
>> sets the read-implies-exec personality thing on old 32-bit binaries.
>
> Ok, so looking at that more closely, if that had worked, we would
> have had PROT_EXEC, and thus VM_EXEC added to the vma by mmap... which
> apparently didn't occur.
>
> I think what may be happening is that the binary he's running has the
> PT_GNU_STACK but his libc doesn't ... the kernel will set the
> personality flag based on the binary you are trying to run, not any
> library it uses...
>
> Kumar, can you try to instrument that a bit and tell us ? What the
> personality flag gets set to and whether mmap sets PROT_EXEC ?
I can and might have already done this, need to double check. But
what I was seeing from elf_map is that we don't get PROT_EXEC set for
this PHDR, but get VM_MAY_EXEC. I'm not clear on what VM_MAY_EXEC is
intended for.
- k
^ 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