* [PATCH 2/3] [POWERPC] fsl_soc: register mpc83xx_wdt for PPC_86xx
From: Anton Vorontsov @ 2008-05-12 18:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Wim Van Sebroeck, Timur Tabi
Since mpc83xx_wdt driver is able to handle MPC86xx watchdogs now,
we want to regster the device appropriately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index a5ceeef..85861c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -545,7 +545,7 @@ err:
arch_initcall(fsl_i2c_of_init);
#endif
-#ifdef CONFIG_PPC_83xx
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_86xx)
static int __init mpc83xx_wdt_init(void)
{
struct resource r;
--
1.5.5.1
^ permalink raw reply related
* [PATCH 1/3] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
From: Anton Vorontsov @ 2008-05-12 18:52 UTC (permalink / raw)
To: Kumar Gala, Wim Van Sebroeck; +Cc: linuxppc-dev, Timur Tabi
On MPC86xx the watchdog could be enabled only at power-on-reset, and
could not be disabled afterwards. We must ping the watchdog from the
kernel until the userspace handles it.
MPC83xx CPUs are only differ in a way that watchdog could be disabled
once, but after it was enabled via software it becomes just the same
as MPC86xx.
Thus, to support MPC86xx I added the kernel timer which pings the
watchdog until the userspace opens it.
Since we implemented the timer, now we're able to implement proper
handling for the CONFIG_WATCHDOG_NOWAYOUT case, for MPC83xx and MPC86xx.
Also move the probe code into subsys_initcall, because we want start
pinging the watchdog ASAP, and misc devices are available in
subsys_initcall.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/watchdog/Kconfig | 4 +-
drivers/watchdog/mpc83xx_wdt.c | 63 ++++++++++++++++++++++++++++++++++++----
2 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 254d115..2929055 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -683,8 +683,8 @@ config 8xx_WDT
depends on 8xx
config 83xx_WDT
- tristate "MPC83xx Watchdog Timer"
- depends on PPC_83xx
+ tristate "MPC83xx/MPC86xx Watchdog Timer"
+ depends on PPC_83xx || PPC_86xx
config MV64X60_WDT
tristate "MV64X60 (Marvell Discovery) Watchdog Timer"
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index b16c5cd..14492a7 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -1,10 +1,12 @@
/*
- * mpc83xx_wdt.c - MPC83xx watchdog userspace interface
+ * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff <dave@cray.org>
* Kumar Gala <galak@kernel.crashing.org>
* Attribution: from 83xx_wst: Florian Schirmer <jolt@tuxbox.org>
* ..and from sc520_wdt
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
*
* Note: it appears that you can only actually ENABLE or DISABLE the thing
* once after POR. Once enabled, you cannot disable, and vice versa.
@@ -22,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/module.h>
#include <linux/watchdog.h>
+#include <linux/timer.h>
#include <asm/io.h>
#include <asm/uaccess.h>
@@ -48,6 +51,11 @@ static int reset = 1;
module_param(reset, bool, 0);
MODULE_PARM_DESC(reset, "Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset");
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+ "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
/*
* We always prescale, but if someone really doesn't want to they can set this
* to 0
@@ -67,6 +75,22 @@ static void mpc83xx_wdt_keepalive(void)
spin_unlock(&wdt_spinlock);
}
+static void mpc83xx_wdt_timer_ping(unsigned long arg);
+static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
+
+static void mpc83xx_wdt_timer_ping(unsigned long arg)
+{
+ mpc83xx_wdt_keepalive();
+ /* We're pinging it twice faster than needed, just to be sure. */
+ mod_timer(&wdt_timer, jiffies + HZ * timeout_sec / 2);
+}
+
+static void mpc83xx_wdt_pr_warn(const char *msg)
+{
+ pr_crit("mpc83xx_wdt: %s, expect the %s soon!\n", msg,
+ reset ? "reset" : "machine check exception");
+}
+
static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -82,7 +106,8 @@ static int mpc83xx_wdt_open(struct inode *inode, struct file *file)
return -EBUSY;
/* Once we start the watchdog we can't stop it */
- __module_get(THIS_MODULE);
+ if (nowayout)
+ __module_get(THIS_MODULE);
/* Good, fire up the show */
if (prescale)
@@ -94,13 +119,17 @@ static int mpc83xx_wdt_open(struct inode *inode, struct file *file)
out_be32(&wd_base->swcrr, tmp);
+ del_timer_sync(&wdt_timer);
+
return nonseekable_open(inode, file);
}
static int mpc83xx_wdt_release(struct inode *inode, struct file *file)
{
- printk(KERN_CRIT "Unexpected close, not stopping watchdog!\n");
- mpc83xx_wdt_keepalive();
+ if (!nowayout)
+ mpc83xx_wdt_timer_ping(0);
+ else
+ mpc83xx_wdt_pr_warn("watchdog closed");
clear_bit(0, &wdt_is_open);
return 0;
}
@@ -152,6 +181,7 @@ static int __devinit mpc83xx_wdt_probe(struct platform_device *dev)
struct resource *r;
int ret;
unsigned int *freq = dev->dev.platform_data;
+ bool enabled;
/* get a pointer to the register memory */
r = platform_get_resource(dev, IORESOURCE_MEM, 0);
@@ -168,6 +198,15 @@ static int __devinit mpc83xx_wdt_probe(struct platform_device *dev)
goto err_out;
}
+ enabled = in_be32(&wd_base->swcrr) & SWCRR_SWEN;
+#ifdef CONFIG_PPC_86xx
+ if (!enabled) {
+ dev_info(&dev->dev, "could not be enabled by software\n");
+ ret = -ENOSYS;
+ goto err_unmap;
+ }
+#endif
+
ret = misc_register(&mpc83xx_wdt_miscdev);
if (ret) {
printk(KERN_ERR "cannot register miscdev on minor=%d "
@@ -185,6 +224,15 @@ static int __devinit mpc83xx_wdt_probe(struct platform_device *dev)
printk(KERN_INFO "WDT driver for MPC83xx initialized. "
"mode:%s timeout=%d (%d seconds)\n",
reset ? "reset":"interrupt", timeout, timeout_sec);
+
+ /*
+ * If the watchdog was previously enabled or we're running on
+ * MPC86xx, we should ping the wdt from the kernel until the
+ * userspace handles it.
+ */
+ if (enabled)
+ mpc83xx_wdt_timer_ping(0);
+
return 0;
err_unmap:
@@ -217,14 +265,17 @@ static int __init mpc83xx_wdt_init(void)
static void __exit mpc83xx_wdt_exit(void)
{
+ /* might happen only on !nowayout */
+ mpc83xx_wdt_pr_warn("module removed");
+ del_timer_sync(&wdt_timer);
platform_driver_unregister(&mpc83xx_wdt_driver);
}
-module_init(mpc83xx_wdt_init);
+subsys_initcall(mpc83xx_wdt_init);
module_exit(mpc83xx_wdt_exit);
MODULE_AUTHOR("Dave Updegraff, Kumar Gala");
-MODULE_DESCRIPTION("Driver for watchdog timer in MPC83xx uProcessor");
+MODULE_DESCRIPTION("Driver for watchdog timer in MPC83xx/MPC86xx uProcessor");
MODULE_LICENSE("GPL");
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
MODULE_ALIAS("platform:mpc83xx_wdt");
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Grant Likely @ 2008-05-12 18:30 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080512173130.0D747181804D@mail89-sin.bigfish.com>
On Mon, May 12, 2008 at 11:31 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> Not easily. As we discussed before, there is nowhere that really
> specifies this information. In some cases I've modified the device tree
> generator to understand what is backward compatible, as with ns16550,
> but for other cores it makes more sense to me to put this compatibility
> information with the driver if it has to be anywhere.
The main concern is that the driver will balloon with data which
impacts the load size for all builds that compile it in. It also
reduces the impact of minor modifications of the IP cores (ie. the
kernel still works when I've up-revved an ip core from 1.00a to
1.00b.)
I understand that it is hard within the EDK TCL scripts context, but
this is exactly what compatible is designed for and I don't think
continually adding more versions to the list is sustainable in the
long term. The more I think about it, the more I'm uneasy about this
approach.
For the time being, I'm going to resist merging this change into my
tree, but I'll keep it in my "don't forget about this" list. It's not
going into .26 anyway, so there is no time pressure. Later, when
we're closer to the .27 merge window, I'll look at it again, but I
really would prefer to find a way to add to the compatible list.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Stephen Neuendorffer @ 2008-05-12 17:31 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40805120724u17a380adnd0826044ae3ac369@mail.gmail.com>
Not easily. As we discussed before, there is nowhere that really
specifies this information. In some cases I've modified the device tree
generator to understand what is backward compatible, as with ns16550,
but for other cores it makes more sense to me to put this compatibility
information with the driver if it has to be anywhere.
Steve
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 7:25 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
>=20
> On Mon, May 5, 2008 at 11:59 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
> > ---
> > drivers/video/xilinxfb.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> > index 848752e..a82c530 100644
> > --- a/drivers/video/xilinxfb.c
> > +++ b/drivers/video/xilinxfb.c
> > @@ -396,6 +396,7 @@ static int __devexit xilinxfb_of_remove(struct
of_device *op)
> > /* Match table for of_platform binding */
> > static struct of_device_id xilinxfb_of_match[] __devinitdata =3D {
> > { .compatible =3D "xlnx,plb-tft-cntlr-ref-1.00.a", },
> > + { .compatible =3D "xlnx,plb-dvi-cntlr-ref-1.00.c", },
>=20
> Can you get the dvi core to claim compatibility with the tft core
> (assuming it is register level backwards compatible)?
>=20
> Cheers,
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 4/6] drivers/net/fs_enet: remove null pointer dereference
From: Scott Wood @ 2008-05-12 17:22 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev, kernel-janitors, linux-kernel, linuxppc-dev, Julia Lawall,
vbordug, jgarzik
In-Reply-To: <20080512165142.GC22190@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Julia Lawall <julia@diku.dk> :
> [...]
>> diff -u -p a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
>> --- a/drivers/net/fs_enet/fs_enet-main.c 2008-04-27 11:41:11.000000000 +0200
>> +++ b/drivers/net/fs_enet/fs_enet-main.c 2008-05-12 09:41:52.000000000 +0200
>> @@ -1093,7 +1093,7 @@ err:
>> if (registered)
>> unregister_netdev(ndev);
>>
>> - if (fep != NULL) {
>> + if (fep && fep->ops) {
>> (*fep->ops->free_bd)(ndev);
>> (*fep->ops->cleanup_data)(ndev);
>> }
>
> Extra cookies for the nice soul who:
> - removes the 'if (registered)' test (it can not happen)
> - uses different error lablels and unrolls the error path. I can not claim
> that the current error path is wrong but it would not hurt if it was more
> trivially balanced.
>
Please note that this code is going away very soon, when arch/ppc dies.
-Scott
^ permalink raw reply
* Re: [PATCH 4/6] drivers/net/fs_enet: remove null pointer dereference
From: Francois Romieu @ 2008-05-12 16:51 UTC (permalink / raw)
To: Julia Lawall
Cc: netdev, kernel-janitors, linux-kernel, linuxppc-dev, vbordug,
jgarzik
In-Reply-To: <Pine.LNX.4.64.0805121537590.3694@ask.diku.dk>
Julia Lawall <julia@diku.dk> :
[...]
> diff -u -p a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> --- a/drivers/net/fs_enet/fs_enet-main.c 2008-04-27 11:41:11.000000000 +0200
> +++ b/drivers/net/fs_enet/fs_enet-main.c 2008-05-12 09:41:52.000000000 +0200
> @@ -1093,7 +1093,7 @@ err:
> if (registered)
> unregister_netdev(ndev);
>
> - if (fep != NULL) {
> + if (fep && fep->ops) {
> (*fep->ops->free_bd)(ndev);
> (*fep->ops->cleanup_data)(ndev);
> }
Extra cookies for the nice soul who:
- removes the 'if (registered)' test (it can not happen)
- uses different error lablels and unrolls the error path. I can not claim
that the current error path is wrong but it would not hurt if it was more
trivially balanced.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] Add null pointer check to of_find_property
From: Timur Tabi @ 2008-05-12 16:46 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1210187999-20274-1-git-send-email-timur@freescale.com>
Timur Tabi wrote:
> Update function of_find_property() to return NULL if the device_node passed
> to it is also NULL. Otherwise, passing NULL will cause a null pointer
> dereference.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Paul, please pick this up for 2.6.26. The legacy_serial driver will crash
without it if there's no 'chosen' node in the device tree. I'm sure there are
other drivers that would crash similarly if given a device tree with missing nodes.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Running a section of code from internal memory
From: Scott Wood @ 2008-05-12 15:56 UTC (permalink / raw)
To: Sanal Kumar V K; +Cc: linuxppc-embedded
In-Reply-To: <48285544.7040908@centillium.com>
Sanal Kumar V K wrote:
> Now if I make the following entry in the linker script,
> /* define L2 scratch here */
> . = 0x9FC16800;
> .l2_scratch : { *(.l2_scratch) }
>
> it says "collect2: ld returned 1 exit status".
I'm guessing there was an earlier error message printed by ld?
You probably located the L2 section too far away from the main section,
and it's trying to do short branches or other limited relocations.
-Scott
^ permalink raw reply
* Re: How to link a .o with all modules
From: Kumar Gala @ 2008-05-12 15:51 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List
In-Reply-To: <9D9C21A5-8796-4FC1-B792-E00112000900@kernel.crashing.org>
On Fri, 9 May 2008, Kumar Gala wrote:
>
> On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote:
>
> > On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote:
> > >
> > > On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
> > >
> > > > > >
> > > > > >
> > > > > > Let me know if this does address your question.
> > > > >
> > > > > The problem is MODPOST complains about undefined symbols:
> > > > >
> > > > > MODPOST 24 modules
> > > > > ERROR: "_restgpr_20_x" [net/key/af_key.ko] undefined!
> > > > > ERROR: "_restgpr_25_x" [net/key/af_key.ko] undefined!
> > > > > ERROR: "_restgpr_30_x" [net/key/af_key.ko] undefined!
> > > >
> > > > I need a bit more context to try to analyse this.
> > > > Where did you expect _restgpr_20_x to be defined.
> > > > If in vmlinux then were they present in the
> > > > Module.symvers file?
> > >
> > > No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I
> > > also be doing EXPORT_SYMBOL?
> >
> > So modpost claim it cannot find the symbols.
> >
> > >
> > > > If in the linked in .o file - could you
> > > > see the symbols using objdump.
> > >
> > > Yes.
> > >
> > > readelf -a:
> > >
> > > ...
> > > Symbol table '.symtab' contains 113 entries:
> > > Num: Value Size Type Bind Vis Ndx Name
> > > ...
> > > 5: 00000000 0 FUNC GLOBAL DEFAULT 1 _savegpr_14
> > > 6: 00000000 0 FUNC GLOBAL DEFAULT 1 _save32gpr_14
> > > ...
> >
> > Strange.
> >
> > I did not look closer.
> > But it looks like the linker failed to resolve these symbols
> > in the final link somehow - despite the symbols are present in
> > the linked in .o file.
> >
> > Can you try to drop me the output of the relocation records for the
> > finally linked .o file (the one with your .o file linked in).
> >
> > objdump -r IIRC
>
> I'm assuming you mean objdump -r arch/powerpc/lib/built-in.o
>
Any update on this?
Here's my current patch that causes me issue:
- k
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..77645a3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -51,7 +51,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.o main.o): \
$(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix $(obj)/,$(zlibheader))
src-libfdt := fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
-src-wlib := string.S crt0.S stdio.c main.c \
+src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
$(addprefix libfdt/,$(src-libfdt)) libfdt-wrapper.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
diff --git a/arch/powerpc/boot/crtsavres.S b/arch/powerpc/boot/crtsavres.S
new file mode 100644
index 0000000..6bac266
--- /dev/null
+++ b/arch/powerpc/boot/crtsavres.S
@@ -0,0 +1,233 @@
+/*
+ * Special support for eabi and SVR4
+ *
+ * Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc.
+ * Written By Michael Meissner
+ * 64-bit support written by David Edelsohn
+ *
+ * This file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file with other programs, and to distribute
+ * those programs without any restriction coming from the use of this
+ * file. (The General Public License restrictions do apply in other
+ * respects; for example, they cover modification of the file, and
+ * distribution when not linked into another program.)
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING. If not, write to
+ * the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ *
+ * As a special exception, if you link this library with files
+ * compiled with GCC to produce an executable, this does not cause
+ * the resulting executable to be covered by the GNU General Public License.
+ * This exception does not however invalidate any other reasons why
+ * the executable file might be covered by the GNU General Public License.
+ */
+
+/* Do any initializations needed for the eabi environment */
+
+ .file "crtsavres.S"
+ .section ".text"
+
+/* On PowerPC64 Linux, these functions are provided by the linker. */
+#ifndef __powerpc64__
+
+#define FUNC_START(name) \
+ .type name,@function; \
+ .globl name; \
+name:
+
+/* Routines for saving integer registers, called by the compiler. */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer save area. */
+
+FUNC_START(_savegpr_14)
+FUNC_START(_save32gpr_14)
+ stw 14,-72(11) /* save gp registers */
+FUNC_START(_savegpr_15)
+FUNC_START(_save32gpr_15)
+ stw 15,-68(11)
+FUNC_START(_savegpr_16)
+FUNC_START(_save32gpr_16)
+ stw 16,-64(11)
+FUNC_START(_savegpr_17)
+FUNC_START(_save32gpr_17)
+ stw 17,-60(11)
+FUNC_START(_savegpr_18)
+FUNC_START(_save32gpr_18)
+ stw 18,-56(11)
+FUNC_START(_savegpr_19)
+FUNC_START(_save32gpr_19)
+ stw 19,-52(11)
+FUNC_START(_savegpr_20)
+FUNC_START(_save32gpr_20)
+ stw 20,-48(11)
+FUNC_START(_savegpr_21)
+FUNC_START(_save32gpr_21)
+ stw 21,-44(11)
+FUNC_START(_savegpr_22)
+FUNC_START(_save32gpr_22)
+ stw 22,-40(11)
+FUNC_START(_savegpr_23)
+FUNC_START(_save32gpr_23)
+ stw 23,-36(11)
+FUNC_START(_savegpr_24)
+FUNC_START(_save32gpr_24)
+ stw 24,-32(11)
+FUNC_START(_savegpr_25)
+FUNC_START(_save32gpr_25)
+ stw 25,-28(11)
+FUNC_START(_savegpr_26)
+FUNC_START(_save32gpr_26)
+ stw 26,-24(11)
+FUNC_START(_savegpr_27)
+FUNC_START(_save32gpr_27)
+ stw 27,-20(11)
+FUNC_START(_savegpr_28)
+FUNC_START(_save32gpr_28)
+ stw 28,-16(11)
+FUNC_START(_savegpr_29)
+FUNC_START(_save32gpr_29)
+ stw 29,-12(11)
+FUNC_START(_savegpr_30)
+FUNC_START(_save32gpr_30)
+ stw 30,-8(11)
+FUNC_START(_savegpr_31)
+FUNC_START(_save32gpr_31)
+ stw 31,-4(11)
+ blr
+
+/* Routines for restoring integer registers, called by the compiler. */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area. */
+
+FUNC_START(_restgpr_14)
+FUNC_START(_rest32gpr_14)
+ lwz 14,-72(11) /* restore gp registers */
+FUNC_START(_restgpr_15)
+FUNC_START(_rest32gpr_15)
+ lwz 15,-68(11)
+FUNC_START(_restgpr_16)
+FUNC_START(_rest32gpr_16)
+ lwz 16,-64(11)
+FUNC_START(_restgpr_17)
+FUNC_START(_rest32gpr_17)
+ lwz 17,-60(11)
+FUNC_START(_restgpr_18)
+FUNC_START(_rest32gpr_18)
+ lwz 18,-56(11)
+FUNC_START(_restgpr_19)
+FUNC_START(_rest32gpr_19)
+ lwz 19,-52(11)
+FUNC_START(_restgpr_20)
+FUNC_START(_rest32gpr_20)
+ lwz 20,-48(11)
+FUNC_START(_restgpr_21)
+FUNC_START(_rest32gpr_21)
+ lwz 21,-44(11)
+FUNC_START(_restgpr_22)
+FUNC_START(_rest32gpr_22)
+ lwz 22,-40(11)
+FUNC_START(_restgpr_23)
+FUNC_START(_rest32gpr_23)
+ lwz 23,-36(11)
+FUNC_START(_restgpr_24)
+FUNC_START(_rest32gpr_24)
+ lwz 24,-32(11)
+FUNC_START(_restgpr_25)
+FUNC_START(_rest32gpr_25)
+ lwz 25,-28(11)
+FUNC_START(_restgpr_26)
+FUNC_START(_rest32gpr_26)
+ lwz 26,-24(11)
+FUNC_START(_restgpr_27)
+FUNC_START(_rest32gpr_27)
+ lwz 27,-20(11)
+FUNC_START(_restgpr_28)
+FUNC_START(_rest32gpr_28)
+ lwz 28,-16(11)
+FUNC_START(_restgpr_29)
+FUNC_START(_rest32gpr_29)
+ lwz 29,-12(11)
+FUNC_START(_restgpr_30)
+FUNC_START(_rest32gpr_30)
+ lwz 30,-8(11)
+FUNC_START(_restgpr_31)
+FUNC_START(_rest32gpr_31)
+ lwz 31,-4(11)
+ blr
+
+/* Routines for restoring integer registers, called by the compiler. */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area. */
+
+FUNC_START(_restgpr_14_x)
+FUNC_START(_rest32gpr_14_x)
+ lwz 14,-72(11) /* restore gp registers */
+FUNC_START(_restgpr_15_x)
+FUNC_START(_rest32gpr_15_x)
+ lwz 15,-68(11)
+FUNC_START(_restgpr_16_x)
+FUNC_START(_rest32gpr_16_x)
+ lwz 16,-64(11)
+FUNC_START(_restgpr_17_x)
+FUNC_START(_rest32gpr_17_x)
+ lwz 17,-60(11)
+FUNC_START(_restgpr_18_x)
+FUNC_START(_rest32gpr_18_x)
+ lwz 18,-56(11)
+FUNC_START(_restgpr_19_x)
+FUNC_START(_rest32gpr_19_x)
+ lwz 19,-52(11)
+FUNC_START(_restgpr_20_x)
+FUNC_START(_rest32gpr_20_x)
+ lwz 20,-48(11)
+FUNC_START(_restgpr_21_x)
+FUNC_START(_rest32gpr_21_x)
+ lwz 21,-44(11)
+FUNC_START(_restgpr_22_x)
+FUNC_START(_rest32gpr_22_x)
+ lwz 22,-40(11)
+FUNC_START(_restgpr_23_x)
+FUNC_START(_rest32gpr_23_x)
+ lwz 23,-36(11)
+FUNC_START(_restgpr_24_x)
+FUNC_START(_rest32gpr_24_x)
+ lwz 24,-32(11)
+FUNC_START(_restgpr_25_x)
+FUNC_START(_rest32gpr_25_x)
+ lwz 25,-28(11)
+FUNC_START(_restgpr_26_x)
+FUNC_START(_rest32gpr_26_x)
+ lwz 26,-24(11)
+FUNC_START(_restgpr_27_x)
+FUNC_START(_rest32gpr_27_x)
+ lwz 27,-20(11)
+FUNC_START(_restgpr_28_x)
+FUNC_START(_rest32gpr_28_x)
+ lwz 28,-16(11)
+FUNC_START(_restgpr_29_x)
+FUNC_START(_rest32gpr_29_x)
+ lwz 29,-12(11)
+FUNC_START(_restgpr_30_x)
+FUNC_START(_rest32gpr_30_x)
+ lwz 30,-8(11)
+FUNC_START(_restgpr_31_x)
+FUNC_START(_rest32gpr_31_x)
+ lwz 0,4(11)
+ lwz 31,-4(11)
+ mtlr 0
+ mr 1,11
+ blr
+#endif
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH v2.6.26] 85xx: Fix some sparse warnings for 85xx MDS
From: Kumar Gala @ 2008-05-12 15:47 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1209751402-25586-1-git-send-email-afleming@freescale.com>
On May 2, 2008, at 1:03 PM, Andy Fleming wrote:
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] SBC8548: Add flash support and HW Rev reporting
From: Kumar Gala @ 2008-05-12 15:46 UTC (permalink / raw)
To: Jeremy McNicoll; +Cc: linuxppc-dev
In-Reply-To: <1210025844-20681-1-git-send-email-jeremy.mcnicoll@windriver.com>
On May 5, 2008, at 5:17 PM, Jeremy McNicoll wrote:
> The following adds local bus, flash and MTD partition nodes for
> sbc8548. As well, a compatible field for the soc node, so that
> of_platform_bus_probe() will pick it up.
>
> Something that is provided through this newly added epld node
> is the Hardware Revision which is now being utilized.
>
> Signed-off-by: Jeremy McNicoll <jeremy.mcnicoll@windriver.com>
> ---
> arch/powerpc/boot/dts/sbc8548.dts | 94 ++++++++++++++++++++++++
> +++++++++
> arch/powerpc/platforms/85xx/sbc8548.c | 30 ++++++++++-
> 2 files changed, 123 insertions(+), 1 deletions(-)
applied (also fixed a few white spaces this introduced).
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 86xx: mpc8610_hpcd: fix second serial port
From: Kumar Gala @ 2008-05-12 15:39 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20080512123533.GA29838@polina.dev.rtsoft.ru>
On May 12, 2008, at 7:35 AM, Anton Vorontsov wrote:
> DIU platform code should not just write to the PIXIS' BRDCFG0
> register,
> it should set and clear its own bits only, otherwise it will break
> firmware setup (in fact it breaks second uart).
>
> Also get rid of magic numbers in the related code.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
From: Kumar Gala @ 2008-05-12 15:39 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080504184627.GA16998@polina.dev.rtsoft.ru>
On May 4, 2008, at 1:46 PM, Anton Vorontsov wrote:
> This patch adds device tree nodes for NOR and NAND flashes and places
> board-control node inside the localbus.
>
> defconfig and board file updated appropriately.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> Heh, this is v2. The flash setup on the MPC8610 tricked me.
>
> There is single NAND package, but with four physical NAND
> chips inside. Each occupy its own localbus CE line, i.e. bank.
>
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 60 +++++++++++++++++-
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 88 ++++++++++++++++++
> ++++++++-
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 +
> 3 files changed, 145 insertions(+), 4 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add 8568 PHY workarounds to board code
From: Kumar Gala @ 2008-05-12 15:39 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <1209772601-28109-1-git-send-email-afleming@freescale.com>
On May 2, 2008, at 6:56 PM, Andy Fleming wrote:
> The 8568 MDS needs some configuration changes to the PHY in order to
> work properly. These are done in the firmware, normally, but Linux
> shouldn't need to rely on the firmware running such things (someone
> could disable the PHY support in the firmware to save space, for
> instance).
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 119 ++++++++++++++++++++
> +++++++++
> 1 files changed, 119 insertions(+), 0 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
From: Kumar Gala @ 2008-05-12 15:39 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080429155333.GC28166@polina.dev.rtsoft.ru>
On Apr 29, 2008, at 10:53 AM, Anton Vorontsov wrote:
> As of current mainline tree, TULIP driver is unusable on MPC8610HPCD
> boards. There is a patch[1] floating around (and also included in the
> BSP), which tries to heal the situation, though the ethernet is still
> unusable. Practically it takes ages to mount NFS filesystem:
>
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 180k init
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 not responding, still trying
>
> So, instead of trying to add uli526x functionality into TULIP driver
> (which is already bloated enough), I fixed existing ULI526X driver
> and now it works perfectly well here.
>
> [1] http://www.bitshrine.org/gpp/0024-MPC8610-ETH-Lyra-native-ethernet.txt
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
applied.
- k
^ permalink raw reply
* Re: [PATCH] Update defconfig for MPC8610 HPCD
From: Kumar Gala @ 2008-05-12 15:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1210370792-23334-1-git-send-email-timur@freescale.com>
On May 9, 2008, at 5:06 PM, Timur Tabi wrote:
> Update the defconfig for the Freescale MPC8610 HPCD board. Enable
> module
> support. Disable support for all NICs except for the on-board
> ULI526x.
> Enable support for the Freescale DIU driver. Increase the maximum
> zone order
> to 12, so that the DIU driver can allocate physically-contiguous 5MB
> buffers.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Support for the Freescale generic DMA driver will have to wait until
> 2.6.27
> because the current audio driver for the 8610 is incompatible with it.
I've updated the defconfig based on some patches from Anton V. Can
you respin this against my powerpc-next branch.
- k
^ permalink raw reply
* Re: [PATCH 4/6] drivers/net/fs_enet: remove null pointer dereference
From: Vitaly Bordug @ 2008-05-12 15:37 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, netdev, kernel-janitors, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0805121537590.3694@ask.diku.dk>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Mon, 12 May 2008 15:38:26 +0200 (CEST)
Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> The following code appears in the function fs_init_instance in the
> file drivers/net/fs_enet/fs_enet-main.c.
>
> if (fep->ops == NULL) {
> printk(KERN_ERR DRV_MODULE_NAME
> ": %s No matching ops found (%d).\n",
> ndev->name, fpi->fs_no);
> err = -EINVAL;
> goto err;
> }
>
> This code implies that at the point of err, fep->ops can be NULL, so
> an extra test is needed before dereferencing this value.
>
>
> This problem was found using the following semantic match
> (http://www.emn.fr/x-info/coccinelle/)
>
> // <smpl>
> @@
> expression E, E1;
> identifier f;
> statement S1,S2,S3;
> @@
>
> * if (E == NULL)
> {
> ... when != if (E == NULL) S1 else S2
> when != E = E1
> * E->f
> ... when any
> return ...;
> }
> else S3
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
>
> diff -u -p a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c ---
> a/drivers/net/fs_enet/fs_enet-main.c 2008-04-27
> 11:41:11.000000000 +0200 +++
> b/drivers/net/fs_enet/fs_enet-main.c 2008-05-12
> 09:41:52.000000000 +0200 @@ -1093,7 +1093,7 @@ err: if (registered)
> unregister_netdev(ndev);
> - if (fep != NULL) {
> + if (fep && fep->ops) {
> (*fep->ops->free_bd)(ndev);
> (*fep->ops->cleanup_data)(ndev);
> }
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Running a section of code from internal memory
From: Sanal Kumar V K @ 2008-05-12 14:33 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080508153315.GC18740@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/html, Size: 4301 bytes --]
^ permalink raw reply
* Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Grant Likely @ 2008-05-12 14:24 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080505175918.2AD03A58056@mail164-sin.bigfish.com>
On Mon, May 5, 2008 at 11:59 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> ---
> drivers/video/xilinxfb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index 848752e..a82c530 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -396,6 +396,7 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
> /* Match table for of_platform binding */
> static struct of_device_id xilinxfb_of_match[] __devinitdata = {
> { .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
> + { .compatible = "xlnx,plb-dvi-cntlr-ref-1.00.c", },
Can you get the dvi core to claim compatibility with the tft core
(assuming it is register level backwards compatible)?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 4/6] drivers/net/fs_enet: remove null pointer dereference
From: Julia Lawall @ 2008-05-12 13:38 UTC (permalink / raw)
To: pantelis.antoniou, vbordug, linuxppc-dev, netdev, linux-kernel,
kernel-janitors
From: Julia Lawall <julia@diku.dk>
The following code appears in the function fs_init_instance in the file drivers/net/fs_enet/fs_enet-main.c.
if (fep->ops == NULL) {
printk(KERN_ERR DRV_MODULE_NAME
": %s No matching ops found (%d).\n",
ndev->name, fpi->fs_no);
err = -EINVAL;
goto err;
}
This code implies that at the point of err, fep->ops can be NULL, so an
extra test is needed before dereferencing this value.
This problem was found using the following semantic match
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@
* if (E == NULL)
{
... when != if (E == NULL) S1 else S2
when != E = E1
* E->f
... when any
return ...;
}
else S3
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
diff -u -p a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
--- a/drivers/net/fs_enet/fs_enet-main.c 2008-04-27 11:41:11.000000000 +0200
+++ b/drivers/net/fs_enet/fs_enet-main.c 2008-05-12 09:41:52.000000000 +0200
@@ -1093,7 +1093,7 @@ err:
if (registered)
unregister_netdev(ndev);
- if (fep != NULL) {
+ if (fep && fep->ops) {
(*fep->ops->free_bd)(ndev);
(*fep->ops->cleanup_data)(ndev);
}
^ permalink raw reply
* Re: MPC5200b external interrupt registration problem
From: Grant Likely @ 2008-05-12 14:03 UTC (permalink / raw)
To: Nick; +Cc: linuxppc-dev
In-Reply-To: <169407.5661.qm@web88102.mail.re2.yahoo.com>
On Fri, May 9, 2008 at 12:49 PM, Nick <ndroogh@rogers.com> wrote:
> Hi,
>
> I am writing a driver to service an interrupt from our fpga. I am calling request_irq in the open
> function of my driver. The fpga is connected to external interrupt 1. I am using interrupt
> number 65 in the request_irq but the function is failing. I traced to a function called setup_irq
> in file /kernel/irq/manage.c. It fails because at this line: if (desc->chip == &no_irq_chip) .
> Is 65 the wrong interrupt number? What do I need to do to properly setup for external interrupts?
What kernel version are you using?
Are you using arch/ppc or arch/powerpc?
There has been a major shift in embedded powerpc support in the last
year. Now, instead of hard coding the peripheral list in the platform
code, the devices are described in an OpenFirmware style device tree.
(See arch/powerpc/boot/dts/lite5200b.dts).
You need to add a node to the tree for your device and specify the
interrupt there. Then use either of_irq_map_one() or
irq_of_parse_and_map() to get something that you can pass to
request_irq().
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-05-12 13:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get 5 commits; one that fixes a compile problem for ARCH=powerpc,
and 4 that fix compile problems for ARCH=ppc. Since 2.6.26 will be
the last release that includes arch/ppc, we probably should make sure
it works in case anyone wants to refer to it subsequently.
Thanks,
Paul.
arch/powerpc/kernel/Makefile | 6 ++++++
arch/powerpc/kernel/cputable.c | 2 ++
arch/powerpc/lib/Makefile | 2 +-
arch/ppc/Makefile | 2 +-
arch/ppc/kernel/ppc_ksyms.c | 1 +
arch/ppc/kernel/setup.c | 1 +
arch/ppc/platforms/residual.c | 1 +
include/asm-ppc/system.h | 2 +-
8 files changed, 14 insertions(+), 3 deletions(-)
Paul Mackerras (2):
[POWERPC] Fix default cputable entries for e200 and e500 families
[POWERPC] ppc: More compile fixes
Segher Boessenkool (3):
[POWERPC] ppc: Use ebony_defconfig for defconfig
[POWERPC] ppc: Include <asm/cacheflush.h> in kernel/ppc_ksyms.c
[POWERPC] ppc: Don't run prom_init_check for arch/ppc builds
^ permalink raw reply
* [PATCH] [POWERPC] 86xx: mpc8610_hpcd: fix second serial port
From: Anton Vorontsov @ 2008-05-12 12:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
DIU platform code should not just write to the PIXIS' BRDCFG0 register,
it should set and clear its own bits only, otherwise it will break
firmware setup (in fact it breaks second uart).
Also get rid of magic numbers in the related code.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 71dbd9d..4c61a10 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -285,11 +285,21 @@ void mpc8610hpcd_set_gamma_table(int monitor_port, char *gamma_table_base)
}
}
+#define PX_BRDCFG0_DVISEL (1 << 3)
+#define PX_BRDCFG0_DLINK (1 << 4)
+#define PX_BRDCFG0_DIU_MASK (PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK)
+
void mpc8610hpcd_set_monitor_port(int monitor_port)
{
- static const u8 bdcfg[] = {0xBD, 0xB5, 0xA5};
+ static const u8 bdcfg[] = {
+ PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK,
+ PX_BRDCFG0_DLINK,
+ 0,
+ };
+
if (monitor_port < 3)
- *pixis_bdcfg0 = bdcfg[monitor_port];
+ clrsetbits_8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK,
+ bdcfg[monitor_port]);
}
void mpc8610hpcd_set_pixel_clock(unsigned int pixclock)
--
1.5.5.1
^ permalink raw reply related
* Re: Compiling applications using cross compiler packs libc
From: Alessandro Rubini @ 2008-05-12 10:27 UTC (permalink / raw)
To: ramkumarj2000; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030805120212r730ded9dv23dfcc29119ebfe5@mail.gmail.com>
> the glibc is also packed
> up as a part of application though I never make any calls to the glibc
> libraries.
As already pointed out by Marco Stornelli, you shouldn't get concerned
about glibc as it's a standard library and you expect it to be part of
the target system (again, use uclibc if size is an issue).
If however you really want to build an application without library, you
should change the linker script. The kernel is not calling main() directly,
there is some initial setup involved, and this is where glibc (or uclibc)
is involved, even if you do no library calls yourself.
Look at a boot loader, or at the kernel, and then to proper
documentation, to find how to provide your own linker script to avoid
a library. But I doubt you really need it.
/alessandro
^ permalink raw reply
* Re: Compiling applications using cross compiler packs libc
From: Marco Stornelli @ 2008-05-12 10:02 UTC (permalink / raw)
To: Ramkumar J; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030805120212r730ded9dv23dfcc29119ebfe5@mail.gmail.com>
Ramkumar J ha scritto:
> Hi All,
>
> I am trying to execute a compiled simple stand-alone application (
> TestApp_Memory.c compiled with gcc 4.1.0 cross compiler for ppc [ I have
> installed this through crosstool on a Linux PC ] ) on the ML403 Board
> instead of using the compiler-set provided by XPS. I tried many options (
> like --static to gcc) to make the object file little as produced by the XPS
> Compiler Set. I find that when static is provided, the glibc is also packed
> up as a part of application though I never make any calls to the glibc
> libraries. If I dont provide the --static, the gcc produces a code assuming
> the library as shared and hence I get an interp section.
> Is there any way to produce the code with only the application and NOT the
> glibc ( As XPS compilers does). Am I missing out something. Is there any
> specific flags. I find even nodefaultlib does not work.
>
> For Eg: This is another example I tried
>
> int main()
> {
> int a = 5;
> int b = 10;
> int c = 15;
>
> c = a + b;
>
> c += 12;
>
> return 0;
> }
>
> With --static compilation, size is about 500K for the above code though the
> useful content is too less. objdump reveals unneccessary calls to the libc.
> Any suggestions would be helpful.
>
> Thanks and Regards,
> Ramkumar
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
You shouldn't use --static but -Os to have a "little" program. With
static you include all the libraries in your application therefore you
have a bigger application. In addition libc are basic libraries so you
have to use it. If you have size problems you can use uclibc.
^ 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