* Re: help with ppc sections?
From: Grant Likely @ 2007-07-26 19:55 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <46A8F22E.6010701@nortel.com>
On 7/26/07, Chris Friesen <cfriesen@nortel.com> wrote:
>
> Hi all,
>
> I'm porting kprobes to 2.6.14, and I think I've got it mostly done. The
> last thing that I want to do is to mark flush_icache_range() as part of
> the .kprobes.text section so that we don't accidently try to probe it.
Hey Chris,
Mild question; What the *@*#^$! are you doing trying to backport to a
2 year old kernel?!? :-)
>
> On ppc64 this was done by duplicating the _GLOBAL macro and just
> modifying the ".section" line.
>
> Unfortunately for me, ppc doesn't have a ".section" line in that macro,
> so I'm at a bit of a loss.
Just add the section. Should be trivial to do. You might have to add
it to the linker script as well.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Reboot Command Makes kernel to hang (MPC8560)
From: Kumar Gala @ 2007-07-26 19:51 UTC (permalink / raw)
To: Ansari; +Cc: linuxppc-embedded
In-Reply-To: <000801c7cf51$f98ebb90$9503a8c0@Ansari>
On Jul 26, 2007, at 1:55 AM, Ansari wrote:
> Hi all,
>
> Processor (MPC8560)
>
> Whenever reboot command is given in the linux console. The
> processor gets reset and it loads bootloader , kernel and when
> uncompressing the ramdisk it gets hang. The sample log is given
> below. Any u please tell me what are the factors that can makes
> this to happen.
This is very board dependant. The MPC8560 doesn't have a clean way
to request reset, and odds are you're only getting the core reset and
not the full chip.
- k
^ permalink raw reply
* Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
From: Sergei Shtylyov @ 2007-07-26 19:52 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-kernel, Alan Cox, linux-ide
In-Reply-To: <Pine.LNX.4.60.0707262136530.6614@poirot.grange>
Hello.
Guennadi Liakhovetski wrote:
>>>driver to using platform-device. I got a reply, that it's not worth it now
>>>that IDE is slowly becoming obsolete, and the pata_platform serves the
>>>perpose perfectly well. I found this argument reasonable, I had the same
>>>doubt, just wanted to double-check. So, why do we now need a new legacy
>>>(a/drivers/ide/legacy/ide_platform.c) driver when a "modern" driver
>>>exists?
>>We don't *need* it but some people still want to use old IDE and the
>>author was willing to make it neatly compatible so that anything that
>>works with the pata_platform should be able to use the ide_platform
>>driver and vice versa. For the shorter term that can only be a good thing
>>- arch code doesn't need to care about which driver is used, end users
>>can pick and it doesn't end up adding new ties between code and old IDE.
> Ok, thanks for the explanation Alan. So, there's no technical argument,
> just "being nice to the users", and add a new driver, which we know we'll
> have to remove soon, thus having to persuade its users, who by that time
Define "soon". :-)
> will get used to it and will not want to invest money into switching to
> another one...
Invest into what if the drivers are functionally identical?
> Thanks
> Guennadi
MBR, Sergei
^ permalink raw reply
* dlopen source
From: Siva Prasad @ 2007-07-26 19:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 122 bytes --]
Hi,
Can some one point to where I can find the source code for dlopen()
function.
Thanks
Siva
[-- Attachment #2: Type: text/html, Size: 1961 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
From: Guennadi Liakhovetski @ 2007-07-26 19:41 UTC (permalink / raw)
To: Alan Cox; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <20070725213925.2f25906c@the-village.bc.nu>
On Wed, 25 Jul 2007, Alan Cox wrote:
> > driver to using platform-device. I got a reply, that it's not worth it now
> > that IDE is slowly becoming obsolete, and the pata_platform serves the
> > perpose perfectly well. I found this argument reasonable, I had the same
> > doubt, just wanted to double-check. So, why do we now need a new legacy
> > (a/drivers/ide/legacy/ide_platform.c) driver when a "modern" driver
> > exists?
>
> We don't *need* it but some people still want to use old IDE and the
> author was willing to make it neatly compatible so that anything that
> works with the pata_platform should be able to use the ide_platform
> driver and vice versa. For the shorter term that can only be a good thing
> - arch code doesn't need to care about which driver is used, end users
> can pick and it doesn't end up adding new ties between code and old IDE.
Ok, thanks for the explanation Alan. So, there's no technical argument,
just "being nice to the users", and add a new driver, which we know we'll
have to remove soon, thus having to persuade its users, who by that time
will get used to it and will not want to invest money into switching to
another one...
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* RE: [RFC][PATCH] MPC832x_RDB: update dts to use spi, registermmc_spi stub
From: Joakim Tjernlund @ 2007-07-26 19:40 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726154747.GA6930@localhost.localdomain>
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]
> Sent: den 26 juli 2007 17:48
> To: Joakim Tjernlund
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
> registermmc_spi stub
>
> On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
> [...]
> > > spi@4c0 {
> > > device_type = "spi";
> > > + device-id = <1>;
> > > compatible = "fsl_spi";
> > > reg = <4c0 40>;
> > > interrupts = <2>;
> > > interrupt-parent = <&qeic>;
> > > - mode = "cpu";
> > > + mode = "qe";
> >
> > The driver is still using "cpu" mode. It just happens that
> the cpu mode for QE
> > enabled CPUs isn't 100% compatible with the defacto cpu
> mode used by other CPU:s.
>
> Yup, indeed.
>
> > So mode should probably be "cpu_qe" or, even better, if the
> drver could
>
> That's easy to change, thanks.
>
> > autodetect that it is running on a QE enabled CPU and
> adjust accordinly.
> > Maybe the Freescale guys have some ideas how to do that.
>
> Ok. Well, for now could we use machine_is() for kind of autodetect?
> Or it's better leave it as is, and just rename mode to cpu_qe?
Unless the DTS guys thinks otherwise, just rename to "cpu_qe".
"qe" would then be reserved for true QE mode.
Jocke
^ permalink raw reply
* Re: [PATCH] [POWERPC] iSeries: fix section mismatch warnings
From: Will Schmidt @ 2007-07-26 19:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070726115601.7733fb96.sfr@canb.auug.org.au>
On Thu, 2007-07-26 at 11:56 +1000, Stephen Rothwell wrote:
> Hi Will,
>
> On Wed, 25 Jul 2007 11:55:31 -0500 Will Schmidt <will_schmidt@vnet.ibm.com> wrote:
> >
> > > cmpwi 0,r24,0 /* Are we processor 0? */
> > > - beq .__start_initialization_iSeries /* Start up the first processor */
> > > - mfspr r4,SPRN_CTRLF
> > > + bne 1f
> > > + b .__start_initialization_iSeries /* Start up the first processor */
> > > +1: mfspr r4,SPRN_CTRLF
> > > li r5,CTRL_RUNLATCH /* Turn off the run light */
> >
> > This part isnt clicking for me..
> > How does changing a "beq" to a "bne" over a "b" fit into changing
> > __start_initialization_iSeries static?
>
> Because I moved __start_initialization_iSeries into another section, it
> ends up too far away for a conditional branch so something adds a jump
> table to the .text section and changes this branch to be via that table.
> Unfortunately, the jump table ends up at the start of the .text and ruins
> our carefully laid out kernel image. By inverting the test I can turn
> the branch into an unconditional one which has a larger possible offse
> (effectively building the jump table manually).
Gotcha, thanks for the clarification. :-)
-Will
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* help with ppc sections?
From: Chris Friesen @ 2007-07-26 19:12 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm porting kprobes to 2.6.14, and I think I've got it mostly done. The
last thing that I want to do is to mark flush_icache_range() as part of
the .kprobes.text section so that we don't accidently try to probe it.
On ppc64 this was done by duplicating the _GLOBAL macro and just
modifying the ".section" line.
Unfortunately for me, ppc doesn't have a ".section" line in that macro,
so I'm at a bit of a loss.
Anyone got any suggestions, or pointers on where I could read up on it?
Chris
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Sergei Shtylyov @ 2007-07-26 17:45 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070726212118.7fe7abd3@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
>>> I acn undertand your complaint in the context of an OF driver
>>>(which we don't have yet) but "mmio-ide" just means nothing to the
>>>current driver, and it doesn't convery enough info on the
>>>programming interface for the conceivable OF driver, it also does
>>>need to know at least "reg-stride" (and maybe "reg-size" in case
>>>only 16/32-bit accesses can be used). Well, if such driver will be
>>>written, I/O mapping support will probably be dropped from it, so
>>>indeed, calling it mmio-ide.c would make sense. But that can be
>>>added when this driver is done, and for now
>>I don't think the details of what Linux code currently exists should
>>drive the device tree binding. That the current patches use
>>platform_device glue code is an implementation detail (and one I'd
>>rather see go away, in favor of a driver that supports both
>>platform_device and of_device).
>>>I'd really prefer the board name to appear in the "compatible" prop
>>>(to which "mmio-ide" can be appended)...
>>Sure, that's always good... it was the "instead" that I objected to.
> Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?
> I am a little bit confused about decided device_type
My understanding is that "ata" has been already used, so there's no sense
in introducing "ide". Anyway, Segher will just say that "device_type" shoudn't
matter and even be present. ;-)
> and compatible fields...
In my understanding, as "mmio-ide" currectly makes no sense, it shouldn't
even appear there. And since "mpc8349emitx-cf" (or whatever would be most
generic name for those boards with the same type of CF IDE mapping) should be
imply the shift value, this property should also be optional, i.e. passing
hard coded value with platform_device would do.
MBR, Sergei
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Scott Wood @ 2007-07-26 17:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070726210507.18829b9a@vitb.ru.mvista.com>
Vitaly Bordug wrote:
> On Thu, 26 Jul 2007 11:45:08 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>>Why not make the fsl spi driver an of_platform device?
>
> Because this particular thing is not ppc-only from what I recall.
spi_mpc83xx.c isn't ppc-only?
Even if it weren't, the OF stuff has been moved out of arch, so a
non-arch-specific driver can support both platform and of_platform
devices directly.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Vitaly Bordug @ 2007-07-26 17:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <46A79AA1.3030608@freescale.com>
On Wed, 25 Jul 2007 13:46:57 -0500
Scott Wood wrote:
> Sergei Shtylyov wrote:
> > I acn undertand your complaint in the context of an OF driver
> > (which we don't have yet) but "mmio-ide" just means nothing to the
> > current driver, and it doesn't convery enough info on the
> > programming interface for the conceivable OF driver, it also does
> > need to know at least "reg-stride" (and maybe "reg-size" in case
> > only 16/32-bit accesses can be used). Well, if such driver will be
> > written, I/O mapping support will probably be dropped from it, so
> > indeed, calling it mmio-ide.c would make sense. But that can be
> > added when this driver is done, and for now
>
> I don't think the details of what Linux code currently exists should
> drive the device tree binding. That the current patches use
> platform_device glue code is an implementation detail (and one I'd
> rather see go away, in favor of a driver that supports both
> platform_device and of_device).
>
> > I'd really prefer the board name to appear in the "compatible" prop
> > (to which "mmio-ide" can be appended)...
>
> Sure, that's always good... it was the "instead" that I objected to.
>
Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?
I am a little bit confused about decided device_type and compatible fields...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Vitaly Bordug @ 2007-07-26 17:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070726164508.GB28491@ld0162-tx32.am.freescale.net>
On Thu, 26 Jul 2007 11:45:08 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
> > +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
> > +EXPORT_SYMBOL(fsl_spi_activate_cs);
> > +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
> > +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
>
> What are these for? It looks like you're using them to set pins,
> but that should be done in the firmware (and if the firmware sucks, then
> do it in the platform code at bootup).
>
That is not exactly the point.
I won't respond for Anton, but we already had such hooks justified in SPI case iirc.
> > +static int __init fsl_spi_of_init(void)
> > +{
> > + struct device_node *np;
> > + unsigned int i;
> > +
> > + for (np = NULL, i = 1;
> > + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
> > + i++) {
>
> s/fsl_spi/fsl,mpc8323-spi/, please.
>
> Why not make the fsl spi driver an of_platform device?
>
Because this particular thing is not ppc-only from what I recall.
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Vitaly Bordug @ 2007-07-26 17:12 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <46A78322.3080607@ru.mvista.com>
On Wed, 25 Jul 2007 21:06:42 +0400
Sergei Shtylyov wrote:
> Hello.
>
> Vitaly Bordug wrote:
>
> > This updates relevant platform code (freescale mpc8349itx target)
> > to make the CompactFlash work in TrueIDE mode.
>
> Erm, I'm not sure it's worth submitting the platform device driver
> for PowerPC at this point, but well...
>
As Ben already confirmed, it is OK to have "constructor" insert platform device if such is
required by design.
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> > arch/powerpc/boot/dts/mpc8349emitx.dts | 9 ++++
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 70
> > +++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+), 0
> > deletions(-)
>
> > diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> > b/arch/powerpc/boot/dts/mpc8349emitx.dts index db0d003..f8f0e8a
> > 100644 --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> > +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> > @@ -37,6 +37,15 @@
> > reg = <00000000 10000000>;
> > };
> >
> > + ide@f0000000 {
> > + compatible = "mmio-ide";
> > + device_type = "ide";
>
> Why not "ata"?
>
we already argued around this iirc. I have no preferences and will put whatever agreed appropriate finally in here.
> > + reg = <f0000000 10 f000020c 4>;
> > + ioport_shift = <1>;
>
> Please use hyphen, not underscore in the property names
> ("device_type" seems an only exception from this rule).
> And since using shift instead of size buys you nothing is this
> case, I'd prefer this property to be called reg-size or reg-stride.
>
> [...]
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > b/arch/powerpc/platforms/83xx/mpc834x_itx.c index 40a0194..d63a104
> > 100644 --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> [...]
> > @@ -43,6 +44,75 @@ unsigned long isa_io_base = 0;
> > unsigned long isa_mem_base = 0;
> > #endif
> >
> > +static int __init mmio_ide_of_init(void)
> > +{
> > + struct device_node *np;
> > + unsigned int i;
> > +
> > + for (np = NULL, i = 0;
> > + (np = of_find_compatible_node(np, "ide",
> > "mmio-ide")) != NULL;
> > + i++) {
> > + int ret = 0;
>
> Unneeded initialization.
>
> > + struct resource res[3];
> > + struct platform_device *pdev = NULL;
>
> Another one.
>
ok
> > + static struct pata_platform_info pdata;
> > +
> > + memset(res, 0, sizeof(res));
> > +
> > + ret = of_address_to_resource(np, 0, &res[0]);
> > + if (ret) {
> > + printk(KERN_ERR "mmio-ide.%d: unable to
> > get "
> > + "resource from OF\n", i);
> > + goto err0;
> > + }
> > +
> > + ret = of_address_to_resource(np, 1, &res[1]);
> > + if (ret) {
> > + printk(KERN_ERR "mmio-ide.%d: unable to
> > get "
> > + "resource from OF\n", i);
> > + goto err0;
>
> Erm, these printk's are repetitive, isn't it better to put them
> under err0 label?
>
> > + }
> > +
> > + res[2].start = res[2].end =
> > irq_of_parse_and_map(np, 0);
> > + if (res[2].start == NO_IRQ) {
> > + printk(KERN_ERR "mmio-ide.%d: no IRQ\n",
> > i);
> > + goto err0;
> > + }
> > + res[2].name = "pata_platform";
> > + res[2].flags = IORESOURCE_IRQ;
> > +
> > + pdata.ioport_shift = *((u32 *)of_get_property(np,
> > + "ioport_shift", NULL));
> > +
> > + pdev = platform_device_alloc("pata_platform", i);
> > + if (!pdev)
> > + goto err1;
>
> Hm, not err0?
>
agreed.
> > +
> > + ret = platform_device_add_data(pdev, &pdata,
> > sizeof(pdata));
> > + if (ret)
> > + goto err1;
> > +
> > + ret = platform_device_add_resources(pdev, res,
> > ARRAY_SIZE(res));
> > + if (ret)
> > + goto err1;
> > +
> > + ret = platform_device_register(pdev);
> > + if (ret)
> > + goto err1;
> > +
> > + continue;
> > +err1:
> > + printk(KERN_ERR "mmio-ide.%d: registration
> > failed\n", i);
> > + platform_device_del(pdev); /* it will free
> > everything */ +err0:
> > + /* Even if some device failed, try others */
> > + continue;
> > + }
> > +
> > + return 0;
> > +}
> > +device_initcall(mmio_ide_of_init);
> > +
> > /*
> > ************************************************************************
> > *
> > * Setup the architecture
>
> MBR, Sergei
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] mpc832x_rdb.c: prevent using uninitialized variable
From: Scott Wood @ 2007-07-26 16:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726140139.GA5709@localhost.localdomain>
On Thu, Jul 26, 2007 at 06:01:39PM +0400, Anton Vorontsov wrote:
> If CONFIG_PCI undefined, np will be used uninitialized, thereby
> find_node_by_name(np, "par_io") will fail.
This is the wrong fix -- you should be passing NULL to the par_io call
rather than np. Otherwise, if the par_io is earlier in the tree than the
pci, you won't find it.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] fsl_soc: add support for fsl_spi
From: Scott Wood @ 2007-07-26 16:45 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070726135655.GA5643@localhost.localdomain>
On Thu, Jul 26, 2007 at 05:56:55PM +0400, Anton Vorontsov wrote:
> +void (*fsl_spi_activate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_activate_cs);
> +void (*fsl_spi_deactivate_cs)(u8 cs, u8 polarity) = NULL;
> +EXPORT_SYMBOL(fsl_spi_deactivate_cs);
What are these for? It looks like you're using them to set pins,
but that should be done in the firmware (and if the firmware sucks, then
do it in the platform code at bootup).
> +static int __init fsl_spi_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> +
> + for (np = NULL, i = 1;
> + (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
> + i++) {
s/fsl_spi/fsl,mpc8323-spi/, please.
Why not make the fsl spi driver an of_platform device?
-Scott
^ permalink raw reply
* [PATCH] make powerpc BUG_ON() OK with pointers and bitwise
From: Al Viro @ 2007-07-26 16:35 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linux-kernel
Since powerpc insists on printing the _value_ of condition
and on casting it to long... At least let's make it a force-cast.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
include/asm-powerpc/bug.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/bug.h b/include/asm-powerpc/bug.h
index f6fa394..a248b8b 100644
--- a/include/asm-powerpc/bug.h
+++ b/include/asm-powerpc/bug.h
@@ -79,7 +79,7 @@
_EMIT_BUG_ENTRY \
: : "i" (__FILE__), "i" (__LINE__), "i" (0), \
"i" (sizeof(struct bug_entry)), \
- "r" ((long)(x))); \
+ "r" ((__force long)(x))); \
} \
} while (0)
--
1.5.3.GIT
^ permalink raw reply related
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-26 16:28 UTC (permalink / raw)
To: Bill Gatliff, gdb, linuxppc-embedded
In-Reply-To: <20070723161512.GA3235@caradoc.them.org>
Daniel Jacobowitz wrote:
> Look around do_signal:
>
> regs->nip -= 4; /* Back up & retry system call */
>
> If your kernel has corrupted the register containing the syscall
> number at this point, that would explain your problem. It will then
> do the wrong syscall. I guess PPC only backs up one instruction.
>
>
Found the code in do_signal, right where you said it would be. I threw
in a printk or two to see what's up when an ERESTARTSYS is detected, and
started getting OOPSes all over the place. Apparently that's not a good
place for printk. :)
Before I go on, can anyone confirm that gdbserver and/or strace _ever_
worked with circa 2.4.16 PPC kernels?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
From: Sergei Shtylyov @ 2007-07-26 16:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <46A7A4EC.2020503@ru.mvista.com>
Hello, I wrote:
>>>>> Also, what mmio-ide in the compat properly means in the context
>>>>>of ide_platform which is able to handle both port and memory mapped
>>>>>IDE.
>>>>I/O-space is only valid in the context of PCI, ISA, or similar buses,
>>>>and
>>>>the bus-specific reg format indicates whether it's mmio-space or
>>>>io-space.
>>> You could save time on lecturing me (and use it to look on the
>>>driver ;-).
>>Sorry, I misread the question as being a mismatch between the
>>capabilities of the device binding and the driver, not about the
>>specific compatible name.
> That too. :-)
>>Something like "generic-ide" would probably be better.
> I strongly disagree with "generic" part. The generic IDE could only be
> said of 1:1 I/O mapped IDE ports, not about this fancy mapping.
BTW, there's already something called drivers/ide/ide-generic.c... :-)
MBR, Sergei
^ permalink raw reply
* Re: Fwd: [PATCH] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Scott Wood @ 2007-07-26 16:04 UTC (permalink / raw)
To: Kumar Gala, Zang Roy-r61911, linuxppc-dev
In-Reply-To: <20070726065902.GD1149@localhost.localdomain>
On Thu, Jul 26, 2007 at 04:59:02PM +1000, David Gibson wrote:
> > >+#define TARGET_HAS_ENET1
> > >+#include "ppcboot.h"
>
> Including ppcboot.h without first defining TARGET_* defines which give
> the type of system seems... fragile at best, broken at worst. Surely
> this can only work by accident.
What target do you suggest he define? There happen to be none in
ppcboot.h that are appropriate, because there are no special fields for
this target (other than eth1).
And yes, it's fragile -- the entire bd_t mechanism is fragile. In the
absence of a time machine, there's not much we can do about it other than
encourage people to upgrade their u-boot.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-07-26 15:47 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <02aa01c7cf9a$aebf3bf0$02ac10ac@Jocke>
On Thu, Jul 26, 2007 at 05:36:06PM +0200, Joakim Tjernlund wrote:
[...]
> > spi@4c0 {
> > device_type = "spi";
> > + device-id = <1>;
> > compatible = "fsl_spi";
> > reg = <4c0 40>;
> > interrupts = <2>;
> > interrupt-parent = <&qeic>;
> > - mode = "cpu";
> > + mode = "qe";
>
> The driver is still using "cpu" mode. It just happens that the cpu mode for QE
> enabled CPUs isn't 100% compatible with the defacto cpu mode used by other CPU:s.
Yup, indeed.
> So mode should probably be "cpu_qe" or, even better, if the drver could
That's easy to change, thanks.
> autodetect that it is running on a QE enabled CPU and adjust accordinly.
> Maybe the Freescale guys have some ideas how to do that.
Ok. Well, for now could we use machine_is() for kind of autodetect?
Or it's better leave it as is, and just rename mode to cpu_qe?
> Jocke
>
> PS.
> Will be on vacation for a week as of tmw, won't have access
> during this time.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Joakim Tjernlund @ 2007-07-26 15:36 UTC (permalink / raw)
To: 'Anton Vorontsov', linuxppc-dev
In-Reply-To: <20070726135738.GB5643@localhost.localdomain>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of Anton Vorontsov
> Sent: den 26 juli 2007 15:58
> To: linuxppc-dev@ozlabs.org
> Subject: [RFC][PATCH] MPC832x_RDB: update dts to use spi,
> register mmc_spi stub
>
> mmc_spi already tested to work. When it will hit mainline
> the only change that would be needed is replacing "spidev"
> by "mmc_spi", and adding trivial platform data to mmc_spi
> driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 33
> ++++++++++++++++++++-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46
> +++++++++++++++++++++++++++++
> 2 files changed, 78 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> index 7c4beff..5dcbdd3 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -183,6 +183,21 @@
> 1 c 1 0 1 0
> /* TX_EN */
> 1 d 2 0 1 0>;
> /* CRS */
> };
> + spi1pio:spi_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain
> assignment has_irq */
> + 3 0 3 0 1 0
> /* SPI1 MOSI, I/O */
> + 3 1 3 0 1 0
> /* SPI1 MISO, I/O */
> + 3 2 3 0 1 0
> /* SPI1 CLK, I/O */
> + 3 3 2 0 1 0>;
> /* SPI1 SEL, I */
> + };
> + mmc1pio:mmc_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain
> assignment has_irq */
> + 3 d 1 0 0 0
> /* !SD_CS */
> + 3 e 2 0 0 0
> /* SD_INSERT */
> + 3 f 2 0 0 0>;
> /* SD_PROTECT */
> + };
> };
> };
>
> @@ -207,20 +222,36 @@
>
> spi@4c0 {
> device_type = "spi";
> + device-id = <1>;
> compatible = "fsl_spi";
> reg = <4c0 40>;
> interrupts = <2>;
> interrupt-parent = <&qeic>;
> - mode = "cpu";
> + mode = "qe";
The driver is still using "cpu" mode. It just happens that the cpu mode for QE
enabled CPUs isn't 100% compatible with the defacto cpu mode used by other CPU:s.
So mode should probably be "cpu_qe" or, even better, if the drver could
autodetect that it is running on a QE enabled CPU and adjust accordinly.
Maybe the Freescale guys have some ideas how to do that.
Jocke
PS.
Will be on vacation for a week as of tmw, won't have access
during this time.
^ permalink raw reply
* need help with 8247 config; bus errors, fcc underruns, etc...
From: Brad Parker @ 2007-07-26 15:34 UTC (permalink / raw)
To: linuxppc-dev
Anyone have direct experience setting up an 8247?
I need some help and am willing to pay for consulting. Please contact
me directly if interested.
Basically I have u-boot running and it will load a kernel via ethernet
(fcc). But once the kernel starts the FCC won't transmit packets bigger
than the fifo (192 bytes) - it gets underuns. It seems to receive fine.
And once and a while it will crash with a machine check. Or a TEA#
error.
I've done all the obvious things but no joy. For some reason this one
doesn't act like the 8260 or 8248.
-brad
Brad Parker
Heeltoe Consulting
+1-781-483-3101
http://www.heeltoe.com
^ permalink raw reply
* Re: About mdio_bus for 82xx based board
From: Scott Wood @ 2007-07-26 15:29 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.tv2nbmkonhx3hy@phoenix>
Alexandros Kostopoulos wrote:
> Well, I've downloaded the latest git from Paul's tree, and some patches
> still fail (and the mpc8272_ads config doesn't compile). Must I get
> some other revision of the tree (if yes, how's that done in git - my
> first time with it )
They don't apply on top of Paul's current tree -- they apply to his tree
as of the time the patchset was posted. I should have a revised
patchset in a week or two (the delay mainly being to add and test a
couple new boards).
-Scott
^ permalink raw reply
* Re: [PATCH] POWERPC: Fix definition of global-utilites structure for 86xx
From: Kumar Gala @ 2007-07-26 15:29 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46A8BA58.4010208@freescale.com>
On Jul 26, 2007, at 10:14 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> Why don't we remove this completely, nothing uses it?
>
> Should I respin the patch to include updates to mpc86xx_restart()
> to use it?
I'm wondering if we should change to code to use a #define GUT_RSTCR
offset value since it only needs one register.
- k
^ permalink raw reply
* Re: DTC 1.0.0 Release Coming?
From: Jon Loeliger @ 2007-07-26 15:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070726142739.GB18684@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> > > Only thing I'm not really happy with in the current release is the
> > > versioning stuff. For starters, it always reports my builds as
> > > -dirty, even when they're not.
> >
> > I think it won't do that once there is a tag available.
>
> Your 1.0.0-rc1 tag is there, still showing as dirty.
Hmmm.. Seems to work here. Is your working directory really clean?
jdl.com 872 % make clean
CLEAN (libfdt)
CLEAN (tests)
CLEAN
jdl.com 873 % make
LEX lex.yy.c
BISON dtc-parser.tab.c
---- Expect 2 s/r and 2 r/r. ----
dtc-parser.y: conflicts: 2 shift/reduce, 2 reduce/reduce
CHK version_gen.h
UPD version_gen.h
CC dtc.o
CC flattree.o
[ snip ]
CC tests/del_node.o
CC tests/truncated_property.o
AS tests/trees.o
DUMPTREES
jdl.com 874 % ./dtc -v
Version: DTC 1.0.0-rc1
I hve also verified that at least one other independent build
using this approach produces a correct version string for them
as well.
> > That is essentially what is there now. We just need a tag!
>
> Um... no. The base version comes from the numbers specified in the
> Makefile, not from the git tag.
Ah, ok. I understand what you mean now. That part.
So run it the other way instead. So perhaps have the
Makefile generate the tag using those versioning parts
instead using some "make tagged_release" target?
> > I would like to keep the current version mechanism as it
> > is really quite similar to what is in the Kernel now.
>
> First, I don't think it really is - except in superficial aspect of
> how the version number is partitioned
I lifted the code from the Kernel's Makefile directly, and tweaked
it slightly for lack of Kconfig aspects.
I don't want to tie the code and build mechanism to git too much.
Specifically, we need to be able to support stand-alone tarball
based builds. For example, I've spoken to the Debian package
maintainer on this issue, and he likes this approach as well as
he says it will make packaging it much easier.
*sigh*
jdl
^ 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