* [PATCH 2/3] Export of_bus_pci_get_flags().
From: Jon Loeliger @ 2007-05-29 18:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/kernel/prom_parse.c | 2 +-
include/asm-powerpc/prom.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..754926f 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -153,7 +153,7 @@ static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
return of_bus_default_translate(addr + 1, offset, na - 1);
}
-static unsigned int of_bus_pci_get_flags(const u32 *addr)
+unsigned int of_bus_pci_get_flags(const u32 *addr)
{
unsigned int flags = 0;
u32 w = addr[0];
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..0168373 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -185,6 +185,7 @@ extern int pci_device_from_OF_node(struct device_node *node,
extern struct device_node* pci_busdev_to_OF_node(struct pci_bus *, int);
extern struct device_node* pci_device_to_OF_node(struct pci_dev *);
extern void pci_create_OF_bus_map(void);
+extern unsigned int of_bus_pci_get_flags(const u32 *addr);
#endif
extern struct resource *request_OF_resource(struct device_node* node,
^ permalink raw reply related
* [PATCH 3/3] Modified quirk_mpc8641_transparent() to initialize bridge resources.
From: Jon Loeliger @ 2007-05-29 18:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Jon Loeliger <jdl@freescale.com>
The 8641 RC poses as a transparent bridge, but does not implement the
IO_BASE or IO_LIMIT registers in the config space. This means that
the code which initializes the bridge resources ends up setting the
IO resources erroneously.
This change initializes the RC bridge resources from the device tree.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 63 +++++++++++++++++++++++++++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 7034bca..94e3c50 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -318,6 +318,7 @@ static void __devinit quirk_uli5288(struct pci_dev *dev)
static void __devinit quirk_uli5229(struct pci_dev *dev)
{
unsigned short temp;
+
pci_write_config_word(dev, 0x04, 0x0405);
dev->class &= ~0x5;
pci_read_config_word(dev, 0x4a, &temp);
@@ -325,9 +326,67 @@ static void __devinit quirk_uli5229(struct pci_dev *dev)
pci_write_config_word(dev, 0x4a, temp);
}
+#define GET_64BIT(prop, i) ((((u64) (prop)[(i)]) << 32) | (prop)[(i)+1])
+
static void __devinit quirk_mpc8641_transparent(struct pci_dev *dev)
{
+ const u32 *ranges;
+ struct resource *res;
+ int len;
+ int i;
+ unsigned int flags;
+ u64 size;
+ struct device_node *node;
+ struct pci_controller *hose;
+
+ /*
+ * Make the bridge be transparent.
+ */
dev->transparent = 1;
+
+ /*
+ * parse ranges property
+ * Ensure IO resource is placed in the PCI_BRIDGE_RESOURCES entry.
+ * PCI #address-cells == 3 and #size-cells == 2 always
+ */
+ node = pci_device_to_OF_node(dev);
+
+ hose = pci_bus_to_hose(dev->bus->number);
+ node = hose->arch_data;
+
+ ranges = of_get_property(node, "ranges", &len);
+ if (ranges == NULL) {
+ printk(KERN_DEBUG "Can't get ranges for PCI-PCI bridge %s\n",
+ node->full_name);
+ return;
+ }
+
+ i = PCI_BRIDGE_RESOURCES + 1;
+ for (; len >= 24; len -= 24, ranges += 6) {
+ flags = of_bus_pci_get_flags(&ranges[0]);
+ size = GET_64BIT(ranges, 4);
+ if (flags == 0 || size == 0)
+ continue;
+ if (flags & IORESOURCE_IO) {
+ res = &dev->resource[PCI_BRIDGE_RESOURCES];
+ if (res->flags) {
+ printk(KERN_ERR "PCI: ignoring extra I/O range"
+ " for bridge %s\n", node->full_name);
+ continue;
+ }
+ } else {
+ if (i >= PCI_NUM_RESOURCES) {
+ printk(KERN_ERR "PCI: too many memory ranges"
+ " for bridge %s\n", node->full_name);
+ continue;
+ }
+ res = &dev->resource[i];
+ ++i;
+ }
+ res->start = GET_64BIT(ranges, 1);
+ res->end = res->start + size - 1;
+ res->flags = flags;
+ }
}
static void __devinit early_uli5249(struct pci_dev *dev)
@@ -344,8 +403,8 @@ static void __devinit early_uli5249(struct pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, quirk_uli1575);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, quirk_uli5288);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, quirk_uli5229);
-DECLARE_PCI_FIXUP_HEADER(0x1957, 0x7010, quirk_mpc8641_transparent);
-DECLARE_PCI_FIXUP_HEADER(0x1957, 0x7011, quirk_mpc8641_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, 0x7010, quirk_mpc8641_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, 0x7011, quirk_mpc8641_transparent);
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AL, 0x5249, early_uli5249);
#endif /* CONFIG_PCI */
^ permalink raw reply related
* Re: pcimsg patch from eons ago
From: Grant Likely @ 2007-05-29 18:25 UTC (permalink / raw)
To: David Hawkins; +Cc: Behan Webster, Linux PPC
In-Reply-To: <465C6596.4030208@ovro.caltech.edu>
On 5/29/07, David Hawkins <dwh@ovro.caltech.edu> wrote:
> Hey Grant,
>
> TCP/IP over PCI is also something I want to look into.
> I'll have about 8 compact PCI crates, with 15 MPC8349E boards
> in each that I will boot with U-Boot, and then TFTP a kernel,
> and then NFS mounted filesystem on. I'll put ethernet on
> the front-panels for the prototype boards, but ideally
> I want TCP/IP over PCI for the final system.
>
> The board support package for the Freescale MPC8349E-MDS-PB
> has some sort of support for this, but I haven't had a look
> at the code yet.
Cool,
I'm not actually going to be using PCI on this project, but it is a
shared memory system, and so I expect the bulk of the protocol could
be similar. The system I'm working on consists of a DSP and an
MPC8349 connected via 128K of shared ram. I need to put together a
low level protocol which will support multiple interfaces on top of
it, and I figured that the old IP-over-PCI would be good place to
start. I need to layer console and filesystem interfaces on top to
begin with, and then additional interfaces as the product matures.
>
> I'm pretty sure Dan Malek had written something similar for
> TCP/IP over RapidIO. Take a look in the kernel source,
> I forget the name ... I have some notes around here somewhere ...
Hmm, yes I hadn't thought of looking at RapidIO. If the low level
protocol was a straight forward message passing interface, then the
stuff on top could potentially be the same.
>
> I'm working on hardware at the moment, so my software
> brain cells are lying dormant. Let me know if you want
> me to dig up the Freescale stuff and I'll send it to you,
> or send you a link to a copy of the ISO. Downloading the
> BSP from Freescale's site is a nightmare. I can also
> plug the MDS board in as a peripheral and fire up their
> TCP/IP over PCI and see what works.
Yes, please send me whatever you have.
> It really shouldn't be too much trouble to get working.
> I started by looking at the PLIP code just to see what
> that took, and its pretty short. The most work would
> be in defining infrastructure to make adding DMA of
> data between the host CPU and the peripherals flexible.
> Most (all?) x86 hosts don't have DMA, so both write and
> read would be handled by the peripheral board. However,
> for PPC hosts with DMA, then writes should be handled
> by the respective boards ... I'm not sure what the
> easiest way to deal with that would be.
>
> Feel free to start a discussion on this :)
>
> Cheers,
> Dave
>
--
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: Arnd Bergmann @ 2007-05-29 18:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <624dd5293b5fde0ffdf01ea692c32e9c@kernel.crashing.org>
On Tuesday 29 May 2007, Segher Boessenkool wrote:
> > right, as mentioned before, IP32L64 would imply introducing a new
> > ABI, which we don't want.
>
> Hey, you could hijack the mswindows ABI, no need to
> define your own ;-)
Windows is IL32P64, not IP32L64
Arnd <><
^ permalink raw reply
* Re: [PATCH] [POWERPC] ps3/interrupt.c uses get_hard_smp_processor_id
From: Geoff Levand @ 2007-05-29 18:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus, cbe-oss-dev
In-Reply-To: <20070528101908.2a5deab8.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> and so needs to include asm/smp.h for a UP build to work.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/platforms/ps3/interrupt.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Becky Bruce @ 2007-05-29 19:04 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <eaf1132805a9531b5131ca51d3e8d9c8@kernel.crashing.org>
On May 29, 2007, at 9:38 AM, Segher Boessenkool wrote:
>> 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
Is anybody within kicking distance of Segher? ;-P
> If what you're
> saying is true in the 2.03 POWER ISA, even for server
> class implementations, that would be very unfortunate.
I believe Category:Server implementations are required to behave as
you expect. Category:Embedded implementations may have different
behavior. Like it or not, BookE *is* part of the Power architecture,
and there are going to be 64-bit implementations of BookE that we
need to take into account.
>
> 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.
I think that's exactly what Kumar's talking about. The assumption
that all 64-bit Power processors will use those upper bits in some
meaningful way is not valid. Also, ld and std do not architecturally
"just work" on BookE implementations running in 32b mode. Those
instructions are part of the 64-bit category in 2.03, and may illop
on BookE processors running in 32b mode.
Cheers,
-Becky
^ permalink raw reply
* Re: [PATCH v2]: Fix e500 v2 core reboot bug
From: Kumar Gala @ 2007-05-29 19:29 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1180406209.8139.13.camel@localhost.localdomain>
On May 28, 2007, at 9:36 PM, Zang Roy-r61911 wrote:
> Fix the e500 v2 core reset bug.
> For e500 v2 core, a new reset control register is added to
> reset the core.
> On 85xx CDS board with e500 v2 core, normal reboot code will
> induce DDR block in u-boot. This patch fixes this bug. It is
> also tested on legacy e500 v1 core.
what happens on an e500 based 85xx system?
I'm not terrible happy with blindly writing to rstcr.
- k
>
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
>
> arch/powerpc/platforms/85xx/misc.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/misc.c b/arch/powerpc/
> platforms/85xx/misc.c
> index 3e62fcb..886a13f 100644
> --- a/arch/powerpc/platforms/85xx/misc.c
> +++ b/arch/powerpc/platforms/85xx/misc.c
> @@ -13,11 +13,29 @@
> #include <linux/irq.h>
> #include <linux/module.h>
> #include <asm/irq.h>
> +#include <asm/io.h>
> +#include <sysdev/fsl_soc.h>
> +
> +static __be32 __iomem *rstcr;
>
> extern void abort(void);
>
> +static int __init mpc85xx_rstcr(void)
> +{
> + /* map reset control register */
> + rstcr = ioremap(get_immrbase() + 0xE00B0, 0xff);
> + return 0;
> +}
> +
> +arch_initcall(mpc85xx_rstcr);
> +
> void mpc85xx_restart(char *cmd)
> {
> local_irq_disable();
> + if (rstcr)
> + /* set reset control register */
> + out_be32(rstcr, 0x2); /* HRESET_REQ */
> + else
> + printk (KERN_EMERG "Error: reset control register not mapped,
> spinning!\n");
> abort();
> }
> --
> 1.5.1
>
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-29 19:29 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Alexandre Bounine, David Gibson, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <a5c459df2eefeb9261e65c551870f7f5@kernel.crashing.org>
On Tue, 2007-05-29 at 16:49 +0200, Segher Boessenkool wrote:
> >>> + 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.
>
> [Assuming what is really on the board is a tsi109...]
For Holly, yes. For Taiga, it's 108. For Hackberry, it's 110.
> I recommend putting both 109 and 108 in the property, in
> that order; that way, if you need to do something special
> on the tsi109 implementation (something you might not yet
> know about perhaps, maybe a bug; or some extra feature on
> the tsi109 device that the driver doesn't handle yet), the
> driver has a chance to do that. If the driver doesn't care
> and only uses tsi108 features, it obviously can probe for
> tsi108 only and all will be fine as well.
*shrug* Either way works for me.
We're adding these compatible properties to DTS files and the drivers at
the same time. Unless (until?) there are firmwares for these boards
that start specifying something else in a real device tree, it really
doesn't matter much. Not that there's anything wrong with your
reasoning. Just seems like we're trying really hard to define something
"correctly" when we control what's on both sides :).
josh
^ permalink raw reply
* Re: [PATCH 2/5] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Kumar Gala @ 2007-05-29 20:39 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1179805110272-git-send-email-wei.zhang@freescale.com>
On May 21, 2007, at 10:38 PM, Zhang Wei wrote:
> Add uli1575 pci-bridge sector. It fixes the issue of ULI1575 not
> found on rev.2 board.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 6 ++++++
> arch/powerpc/boot/dts/mpc8641_hpcn_srio.dts | 6 ++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
> boot/dts/mpc8641_hpcn.dts
> index 260b264..04626b1 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -297,6 +297,12 @@
> interrupts = <49 2>;
> interrupt-parent = <&mpic>;
> };
> + uli1575: uli1575@100 {
is this the right address?
> + reg = <0 0 0 0 0>;
> + pci_bridge@200 {
> + reg = <0 0 0 0 0>;
> + };
> + };
>
> };
Can someone look at merging this with Wade's patch to add the ISA
devices
- k
^ permalink raw reply
* Re: [PATCH 3/3] Modified quirk_mpc8641_transparent() to initialize bridge resources.
From: Kumar Gala @ 2007-05-29 20:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180463004.13106.65.camel@ld0161-tx32>
On May 29, 2007, at 1:23 PM, Jon Loeliger wrote:
> From: Jon Loeliger <jdl@freescale.com>
>
> The 8641 RC poses as a transparent bridge, but does not implement the
> IO_BASE or IO_LIMIT registers in the config space. This means that
> the code which initializes the bridge resources ends up setting the
> IO resources erroneously.
>
> This change initializes the RC bridge resources from the device tree.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Can this be merged with Zhang's "Set RC of mpc8641 to transparent
bridge for transfer legacy I/O access." patch since it pretty much
supersedes it.
- k
^ permalink raw reply
* Re: [PATCH 5/5] Set IDE in ULI1575 to not native mode.
From: Kumar Gala @ 2007-05-29 20:50 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <1179805110284-git-send-email-wei.zhang@freescale.com>
On May 21, 2007, at 10:38 PM, Zhang Wei wrote:
> Set IDE in ULI1575 to not 100% native mode, which forces
> the IDE driver to probe the irq itself.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
What causes this to be needed?
- k
> ---
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index eb2bc99..2a2dea7 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -314,6 +314,7 @@ static void __devinit quirk_uli5229(struct
> pci_dev *dev)
> {
> unsigned short temp;
> pci_write_config_word(dev, 0x04, 0x0405);
> + dev->class &= ~0x5;
> pci_read_config_word(dev, 0x4a, &temp);
> temp |= 0x1000;
> pci_write_config_word(dev, 0x4a, temp);
> --
> 1.5.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Rob Landley @ 2007-05-29 21:02 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070528075507.GA6633@iram.es>
On Monday 28 May 2007 3:55 am, Gabriel Paubert wrote:
> On Fri, May 25, 2007 at 10:38:39PM -0400, Rob Landley wrote:
> > Is anyone already doing this?
>
> I'm interested but I don't have the time right now.
I'm interested but don't have the expertise.
I don't have prep documentation, I'm not familiar with the internals of the
powerpc architecture (beyond the endianness/word size/alignment checklist for
porting userspace programs from arch to arch), I know just enough about Open
Firmware to really dislike it, and I don't actually have prep hardware. I do
have qemu, but it doesn't actually work even with the old ARCH=ppc prep
kernels. It segfaults trying to decompress them.
I was hoping to use a prep kernel to debug qemu, but my build system (which
already builds several other architecutres from the same script) can't do
ARCH=ppc because that doesn't understand "make headers_install", so I have to
build them by hand supplying different architectures at different steps of
the process. Which puts it waaaaay down on my todo list.
Fixing the Linux build system to actually work for prep would be nice, but it
sounds like teaching ARCH=ppc to do "make headers install" would be a couple
orders of magnitude easier...
Rob
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: Rob Landley @ 2007-05-29 21:16 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070527232055.GA23768@localhost.localdomain>
On Sunday 27 May 2007 7:20 pm, David Gibson wrote:
> On Fri, May 25, 2007 at 10:38:39PM -0400, Rob Landley wrote:
> > Is anyone already doing this? I asked around here a few weeks ago and got
the
> > advice:
> >
> > > In theory.. copy the files from ppc/platforms/prep.* to
> > > powerpc/platforms/prep/
> > > and make some Kconfigs and see what breaks :)
>
> Actually, I don't really recommend that method in any case.
>
> Instead I suggest making a Kconfig under arch/powerpc, then adding
> things until it builds, then adding things until it boots. When you
> need to know what has to be done at a particular point, consult
> arch/ppc.
So study the old code until I figure out what should be in the Kconfig,
what "things" to add for it to build, and what "things" to add until it
boots. And the hint as to where to start is... study the old code.
Right. Copying the old implementation to the new directory and debugging it
sounded like something I might be able to do. Starting from scratch? Not so
much.
Rob
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 21:27 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev list, Steve Munroe, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <08b3997ab86a819c63b5cb0afcdc0c9e@kernel.crashing.org>
On Tue, 2007-05-29 at 15:04 +0200, Segher Boessenkool wrote:
>
> 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 :-)
SIGILL you mean ? :-)
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 21:32 UTC (permalink / raw)
To: Kumar Gala
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Anton Blanchard,
Paul Mackerras
In-Reply-To: <9C7D27C7-674E-44B7-A975-69B2E85AB8F2@kernel.crashing.org>
On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> 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.
Yuck. Well, we might need to export a spearate CPU feature bit to
indicate that it's the case then.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Benjamin Herrenschmidt @ 2007-05-29 21:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <B1CC4B3D-D77E-4023-BE92-2A8405998E38@kernel.crashing.org>
On Tue, 2007-05-29 at 08:23 -0500, Kumar Gala wrote:
> 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.
Not sure :-) The code did different things and I didn't want to change
everything at once in that patch. It's on my list to clarify and
possibly fix.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 21:37 UTC (permalink / raw)
To: Steve Munroe
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <OF23D1348F.B2E0AE28-ON862572EA.004C17B2-862572EA.004CF843@us.ibm.com>
On Tue, 2007-05-29 at 09:00 -0500, Steve Munroe wrote:
>
> >
> Yes exactly why make an incompatible ABI change to the powerp32 ABI,
> when you can just use the existing 64-bit ABI.
Why do you keep saying we are making an incompatible ABI change while we
are not ?
> Especially as you can only run what is proposed on 64-bit hardware!
Because people want to do it ... I suspect this has a lot to do with not
having 64 bits pointers or providing specific optimisations in low level
routines within overall 32 bits apps but I don't know the details.
> 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.
BUT WE ARE NOT CHANGING THE BLOODY ABI IN ANY INCOMPATIBLE WAY SHAPE OR
FORM AND THERE IS NO NEED TO CHANGE GLIBC ! Have I been clear enough ?
If not, I'll let Uli explain why again for the 4th time at least.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 21:38 UTC (permalink / raw)
To: Steve Munroe
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180474661.19517.197.camel@localhost.localdomain>
> BUT WE ARE NOT CHANGING THE BLOODY ABI IN ANY INCOMPATIBLE WAY SHAPE OR
> FORM AND THERE IS NO NEED TO CHANGE GLIBC ! Have I been clear enough ?
> If not, I'll let Uli explain why again for the 4th time at least.
Sorry for the shouting... shouldn't reply to email before I had
breakfast :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 5/5] powerpc: Allow ptrace write to pt_regs trap
From: Benjamin Herrenschmidt @ 2007-05-29 21:41 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <OFF7AF7C86.A40E5407-ON422572EA.00560C99-422572EA.00563CD2@de.ibm.com>
On Tue, 2007-05-29 at 17:41 +0200, Ulrich Weigand wrote:
> This doesn't look sufficient. If you want GDB to use the save/
> restore style means of handling interrupted calls (like i386),
> at the very least we also need the capability to *write* the
> orig_gpr3 field, which is currently prohibited. (I don't know
> why this is case, though.)
It's not prohibited afaik ... we allow writing to everything <= MQ (39)
on 32 bits and <= CCR (38) on 64 bits and ORIG_R3 qualifies (34)
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 21:44 UTC (permalink / raw)
To: Steve Munroe
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <OF611013C9.F9C3C2DB-ON862572EA.0050F570-862572EA.005197A3@us.ibm.com>
> But unless you take the time to write it up like a full ABI change you are
> never sure that it IS compatible. And any change to the size/shape of
> ucontext_t is an ABI change.
>
> Also if you want to debug this code (see long long variables correctly from
> GDB or even see the upper 32-bits of GPRs) you will need an ABI change so
> that GDB/DWARF knows what to do.
I personally don't care about gdb seeing those or anything like that,
those would be strictly local asm optimisations, at least that's my
point of view on the matter.
I intend not to extend or change the shape of ucontext neither. I'll add
the highregs after the ucontext32 on the compat signal frame, the only
change/addition is the use of a pad field to point to it and maybe
setting a flag that was previously unused and always 0 to indicate that
it's there.
Do you see any possible compatibility problem there ? Do you know of any
piece of software that makes hard assumptions on the shape and size of a
complete signal frame (not just the ucontext part of it) ?
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Benjamin Herrenschmidt @ 2007-05-29 21:45 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <OF248D3BF7.F4CFDB25-ON422572EA.004A7C17-422572EA.004ACFAE@de.ibm.com>
On Tue, 2007-05-29 at 15:37 +0200, Ulrich Weigand wrote:
>
> 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:
I have to check exactly what's going on there, it might be correct in
both cases, I just remember that the code did something subtely
different but it might result in the same thing. I'll double check
today.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Felix Domke @ 2007-05-29 21:45 UTC (permalink / raw)
To: linuxppc-dev list
In-Reply-To: <1180474079.19517.188.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 15:04 +0200, Segher Boessenkool wrote:
>> 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 :-)
> SIGILL you mean ? :-)
Anyway, please don't. It is *not* portable.
Or can you guarantee that no CPU ever will implement a.) only a 64bit
subset or b.) other instructions using the same encoding as the 64bit
insn you will use for testing?
I still remember the pain of trying to tell that ffmpeg that my CPU
can't do real altivec, even when it implements some parts of it without
SIGILLing (which ffmpeg used for testing).
And: What will happen if you manage to run your code under an operating
system which doesn't even save the upper bits at all on interrupts? You
can't check for that with SIGILL.
Having a decent way (like aux/glibc) would also solve the problem with
"incompatible CPUs", which you mentioned.
And i'd still like to see some decent ILP32LL64 support. Maybe even with
a new "native 64bit" datatype (how ugly), in order to not break the ABI.
I just want to call my hand-optimized 64bit assembler code with 64bit
arguments.
How does OS X handle this? Don't they have the same problem there?
Felix
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-29 23:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180475055.19517.206.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 05/29/2007
04:44:15 PM:
>
> > But unless you take the time to write it up like a full ABI change you
are
> > never sure that it IS compatible. And any change to the size/shape of
> > ucontext_t is an ABI change.
> >
> > Also if you want to debug this code (see long long variables correctly
from
> > GDB or even see the upper 32-bits of GPRs) you will need an ABI change
so
> > that GDB/DWARF knows what to do.
>
> I personally don't care about gdb seeing those or anything like that,
> those would be strictly local asm optimisations, at least that's my
> point of view on the matter.
>
Well others do. If gcc supports code gen for this they will expect GDB
support.
> I intend not to extend or change the shape of ucontext neither. I'll add
> the highregs after the ucontext32 on the compat signal frame, the only
> change/addition is the use of a pad field to point to it and maybe
> setting a flag that was previously unused and always 0 to indicate that
> it's there.
>
The pad field may be occupied with data if the code was compiled on a older
distro and ucontext_t is misaligned (an odd Doubleword). So the pad field
is free for reuse onless you version the code to handle unalligned VMX
registers.
> Do you see any possible compatibility problem there ? Do you know of any
> piece of software that makes hard assumptions on the shape and size of a
> complete signal frame (not just the ucontext part of it) ?
>
The signal frame can change, as long as the relative offset and size of the
ucontext_t is unchanged.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 23:19 UTC (permalink / raw)
To: Steve Munroe
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <OFB4FD81AE.95147932-ON862572EA.007EAB56-862572EA.007FDB77@us.ibm.com>
On Tue, 2007-05-29 at 18:16 -0500, Steve Munroe wrote:
>
> The pad field may be occupied with data if the code was compiled on a
> older
> distro and ucontext_t is misaligned (an odd Doubleword). So the pad
> field
> is free for reuse onless you version the code to handle unalligned VMX
> registers.
Actually... there are two pad areas ... also, I would only use that on
contexts that I generated myself (signal contexts) so I suppose that
should be allright.
> > Do you see any possible compatibility problem there ? Do you know of
> any
> > piece of software that makes hard assumptions on the shape and size
> of a
> > complete signal frame (not just the ucontext part of it) ?
> >
>
> The signal frame can change, as long as the relative offset and size
> of the
> ucontext_t is unchanged.
Ok.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Olof Johansson @ 2007-05-29 23:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180474353.19517.190.camel@localhost.localdomain>
On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> > 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.
>
> Yuck. Well, we might need to export a spearate CPU feature bit to
> indicate that it's the case then.
No need for a new bit, you should be able to key off of PPC_FEATURE_64
&& !PPC_FEATURE_BOOKE.
-Olof
^ 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