* Re: mpc-i2c.c in 2.6
From: Mark A. Greer @ 2005-01-13 21:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Hall, Embedded PPC Linux list
In-Reply-To: <8A6296CC-65A9-11D9-B612-000393DBC2E8@freescale.com>
Kumar Gala wrote:
> Adrian,
>
> I was wondering if you had any opinions on the timeout between
> transactions in drivers/i2c/busses/mpc-i2c. Looking at it, we
> currently set the timeout between transactions to 1 second (HZ). Any
> reason its this high?
>
> on 85xx, I'm able to set it to HZ/100 w/o any really issue.
This is just an FYI since I've been in this code recently. You can
change the timeout from userspace with an ioctl. Something like this
should do it:
static char *usage_msg = "Usage: set_timeout <timeout value>\n";
int main(int argc, char **argv)
{
uint timeout;
int file;
if (argc != 2) {
fprintf(stderr, usage_msg);
return 1;
}
timeout = strtoul(argv[1], NULL, 0);
if ((file = open("/dev/i2c/0", O_RDWR)) < 0) {
printf("Can't open device, errno: %d (%s)\n",
errno, strerror(errno));
return 1;
}
if (ioctl(file, I2C_TIMEOUT, &timeout) < 0) {
printf("Can't do TIMEOUT: %s\n", strerror(errno));
return 1;
}
return 0;
}
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Jörn Engel @ 2005-01-13 21:58 UTC (permalink / raw)
To: Andy Fleming, Kumar Gala, Netdev, Embedded PPC Linux list
In-Reply-To: <20050113212152.GA16041@gate.ebshome.net>
On Thu, 13 January 2005 13:21:52 -0800, Eugene Surovegin wrote:
>
> It's a standard, period. If there is a PHY which isn't compliant I
> guess it will not work anyway, but in this case, yes, we can use
> PHY-specific link detection, but only in this case. I suspect you'll
> have a hard time finding such PHY :)
http://www.broadcom.com/collateral/pb/5325-PB05-R.pdf
With some thinking and very little code, you can use this neat chip
almost like a normal phy.
Jörn
--
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall
^ permalink raw reply
* Re: About Zebra Error
From: Tolunay Orkun @ 2005-01-13 17:07 UTC (permalink / raw)
To: Aubrey Lee; +Cc: linuxppc-embedded
In-Reply-To: <7f834d4e0501130050666b757a@mail.gmail.com>
Aubrey Lee wrote:
> hi, In the PC(i686) system, I build and run zebra successfully. And now
> I'm porting it to the powerpc system. Cross-compiling finished without error.
> But when I run the zebra from my target board, it gives me a big headache:
> --------------------------------------------------------------------------
> bash-2.05b# /opt/zebra/sbin/zebra
> sock: Address family not supported by protocol
> ----------------------------------------------------------------------------
> And Up to now I cann't find the message in the souce
> code files.
You are probably missing the particular socket type Zebra is trying to
use. I had a similar experience while trying to use DHCP in busybox on
by PPC405 embedded system. Go over your kernel configuration and ask a
Zebra mailing list regarding the socket support it needs.
^ permalink raw reply
* Re: Radeon blanking broken
From: Benjamin Herrenschmidt @ 2005-01-14 0:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <jeis6ijlt1.fsf@sykes.suse.de>
On Fri, 2004-12-31 at 20:43 +0100, Andreas Schwab wrote:
> The radeonfb blanking rework has broken it on the iBook G3 wit Radeon M6.
> When the X server enables DPMS the backlight stays on and the display gets
> in a strange state, gradually fading off. When I revert the changes to
> radeon_screen_blank, radeonfb_blank and radeon_set_backlight_enable it
> works again.
This is a real pain actually... I can't seem to find a sequence that
will do proper blanking of the LCD on all models...
It seems each LCD model need a slightly different set of timings etc...
for the blanking procedure.
Ben.
^ permalink raw reply
* [PATCH] I2C-MPC: use wait_event_interruptible_timeout between transactions
From: Kumar Gala @ 2005-01-14 0:21 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, sensors, linuxppc-embedded
Use wait_event_interruptible_timeout so we dont waste time waiting between
transactions like we use to. Also, we use the adapters timeout so the
ioctl cmd I2C_TIMEOUT will now work.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
--
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/13 18:09:31-06:00 galak@cde-tx32-ldt330.sps.mot.com
# use wait_even_interruptible_timeout instead of msleep_interruptible
#
# drivers/i2c/busses/i2c-mpc.c
# 2005/01/13 18:08:40-06:00 galak@cde-tx32-ldt330.sps.mot.com +15 -21
# use wait_even_interruptible_timeout instead of msleep_interruptible
#
diff -Nru a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
--- a/drivers/i2c/busses/i2c-mpc.c 2005-01-13 18:15:58 -06:00
+++ b/drivers/i2c/busses/i2c-mpc.c 2005-01-13 18:15:58 -06:00
@@ -6,7 +6,7 @@
* MPC107/Tsi107 PowerPC northbridge and processors that include
* the same I2C unit (8240, 8245, 85xx).
*
- * Release 0.6
+ * Release 0.7
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
@@ -75,7 +75,6 @@
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
- DECLARE_WAITQUEUE(wait, current);
unsigned long orig_jiffies = jiffies;
u32 x;
int result = 0;
@@ -92,28 +91,22 @@
x = readb(i2c->base + MPC_I2C_SR);
writeb(0, i2c->base + MPC_I2C_SR);
} else {
- set_current_state(TASK_INTERRUPTIBLE);
- add_wait_queue(&i2c->queue, &wait);
- while (!(i2c->interrupt & CSR_MIF)) {
- if (signal_pending(current)) {
- pr_debug("I2C: Interrupted\n");
- result = -EINTR;
- break;
- }
- if (time_after(jiffies, orig_jiffies + timeout)) {
- pr_debug("I2C: timeout\n");
- result = -EIO;
- break;
- }
- msleep_interruptible(jiffies_to_msecs(timeout));
+ /* Interrupt mode */
+ result = wait_event_interruptible_timeout(i2c->queue,
+ (i2c->interrupt & CSR_MIF), timeout * HZ);
+
+ if (unlikely(result < 0))
+ pr_debug("I2C: wait interrupted\n");
+ else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
+ pr_debug("I2C: wait timeout\n");
+ result = -ETIMEDOUT;
}
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&i2c->queue, &wait);
+
x = i2c->interrupt;
i2c->interrupt = 0;
}
- if (result < -0)
+ if (result < 0)
return result;
if (!(x & CSR_MCF)) {
@@ -165,7 +158,7 @@
const u8 * data, int length, int restart)
{
int i;
- unsigned timeout = HZ;
+ unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -193,7 +186,7 @@
static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
- unsigned timeout = HZ;
+ unsigned timeout = i2c->adap.timeout;
int i;
u32 flags = restart ? CCR_RSTA : 0;
@@ -302,6 +295,7 @@
if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
return -ENOMEM;
}
+ memset(i2c, 0, sizeof(*i2c));
i2c->ocpdef = ocp->def;
init_waitqueue_head(&i2c->queue);
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Eugene Surovegin @ 2005-01-14 1:00 UTC (permalink / raw)
To: J?rn Engel; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050113215808.GA15124@wohnheim.fh-wedel.de>
On Thu, Jan 13, 2005 at 10:58:08PM +0100, J?rn Engel wrote:
> On Thu, 13 January 2005 13:21:52 -0800, Eugene Surovegin wrote:
> >
> > It's a standard, period. If there is a PHY which isn't compliant I
> > guess it will not work anyway, but in this case, yes, we can use
> > PHY-specific link detection, but only in this case. I suspect you'll
> > have a hard time finding such PHY :)
>
> http://www.broadcom.com/collateral/pb/5325-PB05-R.pdf
>
> With some thinking and very little code, you can use this neat chip
> almost like a normal phy.
Yeah, but why would I want to? If you connect your MAC to any 5 PHYs
my statement still stands, if directly to MII you don't need any PHY
stuff at all, because link is always ON and speed/duplex is fixed.
In fact, we use different switch chips connected to PPC4xx directly.
In this situation, in my NAPI IBM EMAC driver I just have special
"PHY-less" case which is trivial "fixed settings" one. And all this
PHY lib is completely unneeded bloat.
--
Eugene
^ permalink raw reply
* [PATCH] I2C-MPC: Convert to platform_device driver
From: Kumar Gala @ 2005-01-14 3:35 UTC (permalink / raw)
To: greg; +Cc: linux-kernel, sensors, linuxppc-embedded
Converted the driver to work as either a OCP or platform_device driver.
The intent in the future (once we convert all PPC sub-archs from OCP to
platform_device) is to remove the OCP code.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig 2005-01-13 21:27:38 -06:00
+++ b/drivers/i2c/busses/Kconfig 2005-01-13 21:27:38 -06:00
@@ -208,7 +208,7 @@
config I2C_MPC
tristate "MPC107/824x/85xx/52xx"
- depends on I2C && FSL_OCP
+ depends on I2C && PPC
help
If you say yes to this option, support will be included for the
built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245 and
diff -Nru a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
--- a/drivers/i2c/busses/i2c-mpc.c 2005-01-13 21:27:38 -06:00
+++ b/drivers/i2c/busses/i2c-mpc.c 2005-01-13 21:27:38 -06:00
@@ -1,12 +1,12 @@
/*
* (C) Copyright 2003-2004
* Humboldt Solutions Ltd, adrian@humboldt.co.uk.
-
+
* This is a combined i2c adapter and algorithm driver for the
* MPC107/Tsi107 PowerPC northbridge and processors that include
- * the same I2C unit (8240, 8245, 85xx).
+ * the same I2C unit (8240, 8245, 85xx).
*
- * Release 0.7
+ * Release 0.8
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without any
@@ -20,7 +20,13 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <asm/io.h>
+#ifdef CONFIG_FSL_OCP
#include <asm/ocp.h>
+#define FSL_I2C_DEV_SEPARATE_DFSRR FS_I2C_SEPARATE_DFSRR
+#define FSL_I2C_DEV_CLOCK_5200 FS_I2C_CLOCK_5200
+#else
+#include <linux/fsl_devices.h>
+#endif
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
@@ -50,10 +56,11 @@
struct mpc_i2c {
char *base;
- struct ocp_def *ocpdef;
u32 interrupt;
wait_queue_head_t queue;
struct i2c_adapter adap;
+ int irq;
+ u32 flags;
};
static __inline__ void writeccr(struct mpc_i2c *i2c, u32 x)
@@ -79,7 +86,8 @@
u32 x;
int result = 0;
- if (i2c->ocpdef->irq == OCP_IRQ_NA) {
+ if (i2c->irq == 0)
+ {
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
if (time_after(jiffies, orig_jiffies + timeout)) {
@@ -92,7 +100,7 @@
writeb(0, i2c->base + MPC_I2C_SR);
} else {
/* Interrupt mode */
- result = wait_event_interruptible_timeout(i2c->queue,
+ result = wait_event_interruptible_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout * HZ);
if (unlikely(result < 0))
@@ -130,12 +138,11 @@
static void mpc_i2c_setclock(struct mpc_i2c *i2c)
{
- struct ocp_fs_i2c_data *i2c_data = i2c->ocpdef->additions;
/* Set clock and filters */
- if (i2c_data && (i2c_data->flags & FS_I2C_SEPARATE_DFSRR)) {
+ if (i2c->flags & FSL_I2C_DEV_SEPARATE_DFSRR) {
writeb(0x31, i2c->base + MPC_I2C_FDR);
writeb(0x10, i2c->base + MPC_I2C_DFSRR);
- } else if (i2c_data && (i2c_data->flags & FS_I2C_CLOCK_5200))
+ } else if (i2c->flags & FSL_I2C_DEV_CLOCK_5200)
writeb(0x3f, i2c->base + MPC_I2C_FDR);
else
writel(0x1031, i2c->base + MPC_I2C_FDR);
@@ -287,6 +294,7 @@
.retries = 1
};
+#ifdef CONFIG_FSL_OCP
static int __devinit mpc_i2c_probe(struct ocp_device *ocp)
{
int result = 0;
@@ -296,7 +304,9 @@
return -ENOMEM;
}
memset(i2c, 0, sizeof(*i2c));
- i2c->ocpdef = ocp->def;
+
+ i2c->irq = ocp->def->irq;
+ i2c->flags = ((struct ocp_fs_i2c_data *)ocp->def->additions)->flags;
init_waitqueue_head(&i2c->queue);
if (!request_mem_region(ocp->def->paddr, MPC_I2C_REGION, "i2c-mpc")) {
@@ -312,16 +322,20 @@
goto fail_map;
}
- if (ocp->def->irq != OCP_IRQ_NA)
+ if (i2c->irq != OCP_IRQ_NA)
+ {
if ((result = request_irq(ocp->def->irq, mpc_i2c_isr,
0, "i2c-mpc", i2c)) < 0) {
printk(KERN_ERR
"i2c-mpc - failed to attach interrupt\n");
goto fail_irq;
}
+ } else
+ i2c->irq = 0;
i2c->adap = mpc_ops;
i2c_set_adapdata(&i2c->adap, i2c);
+
if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
goto fail_add;
@@ -348,9 +362,9 @@
i2c_del_adapter(&i2c->adap);
if (ocp->def->irq != OCP_IRQ_NA)
- free_irq(i2c->ocpdef->irq, i2c);
+ free_irq(i2c->irq, i2c);
iounmap(i2c->base);
- release_mem_region(i2c->ocpdef->paddr, MPC_I2C_REGION);
+ release_mem_region(ocp->def->paddr, MPC_I2C_REGION);
kfree(i2c);
}
@@ -380,6 +394,101 @@
module_init(iic_init);
module_exit(iic_exit);
+#else
+static int fsl_i2c_probe(struct device *device)
+{
+ int result = 0;
+ struct mpc_i2c *i2c;
+ struct platform_device *pdev = to_platform_device(device);
+ struct fsl_i2c_platform_data *pdata;
+ struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
+
+ if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
+ return -ENOMEM;
+ }
+ memset(i2c, 0, sizeof(*i2c));
+
+ i2c->irq = platform_get_irq(pdev, 0);
+ i2c->flags = pdata->device_flags;
+ init_waitqueue_head(&i2c->queue);
+
+ i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
+
+ if (!i2c->base) {
+ printk(KERN_ERR "i2c-mpc - failed to map controller\n");
+ result = -ENOMEM;
+ goto fail_map;
+ }
+
+ if (i2c->irq != 0)
+ if ((result = request_irq(i2c->irq, mpc_i2c_isr,
+ 0, "fsl-i2c", i2c)) < 0) {
+ printk(KERN_ERR
+ "i2c-mpc - failed to attach interrupt\n");
+ goto fail_irq;
+ }
+
+ i2c->adap = mpc_ops;
+ i2c_set_adapdata(&i2c->adap, i2c);
+ i2c->adap.dev.parent = &pdev->dev;
+ if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
+ printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
+ goto fail_add;
+ }
+
+ mpc_i2c_setclock(i2c);
+ dev_set_drvdata(device, i2c);
+ return result;
+
+ fail_add:
+ if (i2c->irq != 0)
+ free_irq(i2c->irq, 0);
+ fail_irq:
+ iounmap(i2c->base);
+ fail_map:
+ kfree(i2c);
+ return result;
+};
+
+static int fsl_i2c_remove(struct device *device)
+{
+ struct mpc_i2c *i2c = dev_get_drvdata(device);
+
+ dev_set_drvdata(device, NULL);
+ i2c_del_adapter(&i2c->adap);
+
+ if (i2c->irq != 0)
+ free_irq(i2c->irq, i2c);
+
+ iounmap(i2c->base);
+ kfree(i2c);
+ return 0;
+};
+
+/* Structure for a device driver */
+static struct device_driver fsl_i2c_driver = {
+ .name = "fsl-i2c",
+ .bus = &platform_bus_type,
+ .probe = fsl_i2c_probe,
+ .remove = fsl_i2c_remove,
+};
+
+static int __init fsl_i2c_init(void)
+{
+ return driver_register(&fsl_i2c_driver);
+}
+
+static void __exit fsl_i2c_exit(void)
+{
+ driver_unregister(&fsl_i2c_driver);
+}
+
+module_init(fsl_i2c_init);
+module_exit(fsl_i2c_exit);
+
+#endif /* CONFIG_FSL_OCP */
MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
MODULE_DESCRIPTION
^ permalink raw reply
* Kernel 2.6.x to MPC8540/Microsys Board
From: Clemens Koller @ 2005-01-14 10:50 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am about to do my first steps to boot a 2.6 Kernel on the
PM854 Board from Microsys (MPC8540) to see how well it works.
I use U-Boot 1.1.2 and the 2.4.26 Kernel from Microsys compiles and
runs fine on the Board as intended.
Now I 've tried the official 2.6.10 Kernel and (cross-)compiled it
within ELDK 3.1 (btw: is there any difference in between ppc_6xx- and
ppc_82xx- ?) which works fine, too.
I just started with the mpc8540ads platform with early printk and
otherwise everything disabled (I want a small kernel) and manually
built the vmlinux.UBoot using mkimage. I just want to see if
something comes up to the console (serial port). Well, currently,
it stops at:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
mpc8540ads_init(): exit
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
mpc8540ads_setup_arch()
arch: exit
openpic: enter
openpic: timer
openpic: external
openpic: spurious
openpic: exit
Okay. I am not really worried about that... at least I got a sign of
life and debugging output :-)
My questions are now:
Which is the best Kernel source tree to start porting 2.6.x to the pm854
platform? I would prefer to stuck with the official sources. Is that a
good idea?
Is it a good idea to just 'copy' the pm854 platform specific files (PCI
initialization and some MTD driver options) to the 2.6.10 tree and see
how it works?
As there anybody who has already a working 2.6.10-something for MPC8540
(well, non mpc8540ads).
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Wolfgang Denk @ 2005-01-14 11:31 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <41E7A410.6060008@anagramm.de>
In message <41E7A410.6060008@anagramm.de> you wrote:
>
> Now I 've tried the official 2.6.10 Kernel and (cross-)compiled it
> within ELDK 3.1 (btw: is there any difference in between ppc_6xx- and
> ppc_82xx- ?) which works fine, too.
ppc_82xx is a symbolic link ppc_6xx
> Which is the best Kernel source tree to start porting 2.6.x to the pm854
> platform? I would prefer to stuck with the official sources. Is that a
> good idea?
Yes.
> Is it a good idea to just 'copy' the pm854 platform specific files (PCI
> initialization and some MTD driver options) to the 2.6.10 tree and see
> how it works?
Copy from where? from 2.4? No.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A fail-safe circuit will destroy others. -- Klipstein
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Sam Song @ 2005-01-14 13:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050114113126.434C4C108D@atlas.denx.de>
Wolfgang Denk <wd@denx.de> wrote:
> > Now I 've tried the official 2.6.10 Kernel and
> > (cross-)compiled it
> > within ELDK 3.1 (btw: is there any difference in
> > between ppc_6xx- and
> > ppc_82xx- ?) which works fine, too.
>
> ppc_82xx is a symbolic link ppc_6xx
Well, I also have a puzzle here. In ELDK3.1, could
ppc_6xx package work for 6xx/7xx/82xx[603e] and 85xx
[e500] target at the same time?
Thanks in advance!
=====
Best regards,
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜,带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有,搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆,雅虎电邮自助扩容!
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-14 14:03 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050113151646.GZ3391@smtp.west.cox.net>
> -----Original Message-----
> From: Tom Rini [mailto:trini@kernel.crashing.org]
> On Wed, Jan 12, 2005 at 08:15:08AM -0700, Tom Rini wrote:
> > On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > > > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> [snip]
> > > > > Patch looks good to me, but I want to ask when this error
> > > > > can be triggered in practice?
> > > >
> > > > It is possible to see this in the real world, as we (<hat=mvista>) found
> > > > this with a customers app.
> > >
> > > hmm, this app must have been doing something pretty special. Any idea what
> > > caused it?
> >
> > Only vaugely. I'll poke the folks who did the investigation to see if
> > they recall (the app is quite large) and follow up with details, I hope.
>
> First, we couldn't get this issue to happen w/ anything but the custom
> app. It would generate a lot of I-TLB Error exceptions, with bit 1 of
> SRR1 set, and these went fine, the I-TLB got updated, and execution
> continued. But then at some point, and we aren't sure why exactly, an
> 0x1100 is generated, and we crash. We don't know what went and caused
> an 0x1100 to be generated instead of an 0x1300 (my wild-ass-guess is the
> code jumped very very far ahead).
To me this looks like you entered the I-TLB Miss handler with a NULL pte which
is something that never happens in my system, don't know why this is so but I am
guessing that the kernel populates all instruction pte's at exec time. On the
other hand I don't understand why there are so many I-TLB errors, is that normal?
Does the app modify its own code or construct a code trampoline which it jumps to? Not
sure how that would be handled by the kernel w.r.t NULL pte's
Jocke
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Clemens Koller @ 2005-01-14 14:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050114113126.434C4C108D@atlas.denx.de>
Wolfgang Denk wrote:
>>Which is the best Kernel source tree to start porting 2.6.x to the pm854
>>platform? I would prefer to stuck with the official sources. Is that a
>>good idea?
>
> Yes.
Thank you, that's what I wanted to hear :-)
>>Is it a good idea to just 'copy' the pm854 platform specific files (PCI
>> initialization and some MTD driver options) to the 2.6.10 tree and see
>>how it works?
>
> Copy from where? from 2.4? No.
Well, I don't know how the platform specific things got moved from 2.4
to 2.6 in the past (yes I am a newbie). I have a working
2.4.26-pm854-something with a platform/pm854_defconfig (and some changed
non-official(?) files for the PCI and MTDs) and I want to get the same
for 2.6.10+ without changing things at the wrong place.
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Kumar Gala @ 2005-01-14 14:43 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <41E7A410.6060008@anagramm.de>
[snip]
> My questions are now:
> Which is the best Kernel source tree to start porting 2.6.x to the=20
> pm854
> platform? I would prefer to stuck with the official sources. Is that a
> good idea?
I would suggest 2.6.10 if you want an official kernel release. Is this=20=
board generally available to people? If so, and you want support for=20
this board in the official kernel, send me your patches for review. =20
I'll then push them up stream.
Be aware there are some infrastrucal changes I'm working on that moves=20=
the 85xx sub-arch support from using OCP to platform_device. However,=20=
these have minor changes on the board files.
> Is it a good idea to just 'copy' the pm854 platform specific files =
(PCI
> =A0 initialization and some MTD driver options) to the 2.6.10 tree and=20=
> see
> how it works?
I would take a look at how 2.6 is structured for 85xx. I tried to do a=20=
better job and provide more common code for a board port to leverage. =20=
So for something like PCI, you should hopefully just have to setup your=20=
memory map and IRQ routing.
> As there anybody who has already a working 2.6.10-something for =
MPC8540
> (well, non mpc8540ads).
I'm not aware of anyone else with another MPC8540 port, I know of other=20=
MPC8560's, and MPC8555/41 ports.
- kumar
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Jörn Engel @ 2005-01-14 14:55 UTC (permalink / raw)
To: Andy Fleming, Kumar Gala, Netdev, Embedded PPC Linux list
In-Reply-To: <20050114010016.GA16635@gate.ebshome.net>
On Thu, 13 January 2005 17:00:16 -0800, Eugene Surovegin wrote:
> On Thu, Jan 13, 2005 at 10:58:08PM +0100, J?rn Engel wrote:
> >
> > http://www.broadcom.com/collateral/pb/5325-PB05-R.pdf
> >
> > With some thinking and very little code, you can use this neat chip
> > almost like a normal phy.
>
> Yeah, but why would I want to? If you connect your MAC to any 5 PHYs
> my statement still stands, if directly to MII you don't need any PHY
> stuff at all, because link is always ON and speed/duplex is fixed.
>
> In fact, we use different switch chips connected to PPC4xx directly.
> In this situation, in my NAPI IBM EMAC driver I just have special
> "PHY-less" case which is trivial "fixed settings" one. And all this
> PHY lib is completely unneeded bloat.
Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the
code, it's mere size said enough.
But an abstraction different from drivers/net/mii.c is needed to
handle the 5325 chip. Or, you could have the special cases all over
in your code, but that's a) ugly and b) more code. I used to have
such a mess and after doing the proper abstraction, it line count went
down.
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Eugene Surovegin @ 2005-01-14 15:25 UTC (permalink / raw)
To: J?rn Engel; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050114145518.GA21418@wohnheim.fh-wedel.de>
On Fri, Jan 14, 2005 at 03:55:18PM +0100, J?rn Engel wrote:
> Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the
> code, it's mere size said enough.
>
> But an abstraction different from drivers/net/mii.c is needed to
> handle the 5325 chip. Or, you could have the special cases all over
> in your code, but that's a) ugly and b) more code. I used to have
> such a mess and after doing the proper abstraction, it line count went
> down.
Well, I still fail to see what is so _special_ about this chip that it
needs "proper abstraction". Could you elaborate, please?
The way I handled this in my drivers was clean and simple -
"there-is-no-PHY". And this wasn't in any case chip-specific and was
set up through OCP in board support code. So I'm kinda puzzled what
"ugliness and more code" you are talking about.
We can also make a fake PHY which will always indicate link, will have
fixed speed/duplex capabilities and will not support autoneg. If you
think this is more elegant, OK, I might even agree with you :).
Please, note that wrt current discussion we are interested only in CPU
port, not other 5 ports which aren't connected to the CPU at all. This
is completely different stuff and yes, if we want to expose them in
some way we need another abstraction. But abstraction of switch chips
is a big and complex thing - they are very different, and frankly this
one you mentioned is quite "feature-challenged" and will not make
a good "model" chip IMHO :).
--
Eugene
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Clemens Koller @ 2005-01-14 15:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <B29E7784-663A-11D9-A3DB-000393DBC2E8@freescale.com>
Kumar Gala wrote:
> I would suggest 2.6.10 if you want an official kernel release. Is this
> board generally available to people?
Yes: www.microsys.de miriac Module: PM854 (and some others)
> Be aware there are some infrastrucal changes I'm working on that moves
> the 85xx sub-arch support from using OCP to platform_device. However,
> these have minor changes on the board files.
I've read your last mails in this list... therefore I am asking. :-)
I just don't want to re-invent the wheel twice. In the pm854 specific
things there are also some OCP updates. (Well, I am still reading lots
of code... newland for me)
I try to contact the developer Josef Wagner at Microsys who was working
on the 2.4.26-sth.
> I would take a look at how 2.6 is structured for 85xx. I tried to do a
> better job and provide more common code for a board port to leverage.
> So for something like PCI, you should hopefully just have to setup your
> memory map and IRQ routing.
I am comparing 2.4.26-sth with 2.6.10 now. The changes are manageable as
far as I got it. Where can I get the current work from you?!
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Kumar Gala @ 2005-01-14 15:47 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <41E7E64F.2080807@anagramm.de>
Clemens,
I would to just use 2.6.10 as starting point and get that working. The=20=
amount of changes to board code is about 100 lines to go from OCP to=20
platform_device. I should be releasing patches for this upstream today=20=
and will CC the linuxppc-embedded list, so if you really want them you=20=
can get them, but I dont think its worth the pain for you.
- kumar
On Jan 14, 2005, at 9:33 AM, Clemens Koller wrote:
> Kumar Gala wrote:
>
> > I would suggest 2.6.10 if you want an official kernel release.=A0 Is=20=
> this
> > board generally available to people?
>
> Yes: www.microsys.de miriac Module: PM854 (and some others)
>
> > Be aware there are some infrastrucal changes I'm working on that=20
> moves
> > the 85xx sub-arch support from using OCP to platform_device.=A0=20
> However,
> > these have minor changes on the board files.
>
> I've read your last mails in this list... therefore I am asking. :-)
> I just don't want to re-invent the wheel twice. In the pm854 specific
> things there are also some OCP updates. (Well, I am still reading =
lots
> of code... newland for me)
> I try to contact the developer Josef Wagner at Microsys who was=20
> working
> on the 2.4.26-sth.
>
> > I would take a look at how 2.6 is structured for 85xx.=A0 I tried to=20=
> do a
> > better job and provide more common code for a board port to=20
> leverage.=A0
> > So for something like PCI, you should hopefully just have to setup=20=
> your
> > memory map and IRQ routing.
>
> I am comparing 2.4.26-sth with 2.6.10 now. The changes are manageable=20=
> as
> far as I got it. Where can I get the current work from you?!
>
> Greets,
>
> Clemens Koller
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Jörn Engel @ 2005-01-14 15:49 UTC (permalink / raw)
To: Andy Fleming, Kumar Gala, Netdev, Embedded PPC Linux list
In-Reply-To: <20050114152518.GB23768@gate.ebshome.net>
On Fri, 14 January 2005 07:25:18 -0800, Eugene Surovegin wrote:
> On Fri, Jan 14, 2005 at 03:55:18PM +0100, J?rn Engel wrote:
> > Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the
> > code, it's mere size said enough.
> >
> > But an abstraction different from drivers/net/mii.c is needed to
> > handle the 5325 chip. Or, you could have the special cases all over
> > in your code, but that's a) ugly and b) more code. I used to have
> > such a mess and after doing the proper abstraction, it line count went
> > down.
>
> Well, I still fail to see what is so _special_ about this chip that it
> needs "proper abstraction". Could you elaborate, please?
>
> The way I handled this in my drivers was clean and simple -
> "there-is-no-PHY". And this wasn't in any case chip-specific and was
> set up through OCP in board support code. So I'm kinda puzzled what
> "ugliness and more code" you are talking about.
>
> We can also make a fake PHY which will always indicate link, will have
> fixed speed/duplex capabilities and will not support autoneg. If you
> think this is more elegant, OK, I might even agree with you :).
Exactly. You need link status, speed and duplex status at the least.
Put query functions for those three into a struct phy_ops or whatever
it may be called and you're done.
Depending on your hardware, you may also need something more
complicated for various fixups, etc. But it's mostly those three
functions.
> Please, note that wrt current discussion we are interested only in CPU
> port, not other 5 ports which aren't connected to the CPU at all. This
> is completely different stuff and yes, if we want to expose them in
> some way we need another abstraction. But abstraction of switch chips
> is a big and complex thing - they are very different, and frankly this
> one you mentioned is quite "feature-challenged" and will not make
> a good "model" chip IMHO :).
Well, it's one of the few I've had to worry about so far. I'm a big
non-believer in abstractions I just don't need yet. The one outlined
above I already needed.
Jörn
--
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918
^ permalink raw reply
* ELDK on a PowerPC host machine?
From: annamaya @ 2005-01-14 15:51 UTC (permalink / raw)
To: linuxppc-embedded
I noticed that ELDK from denx does not support running
on a PowerPC host machine like the Power G4 or G5.
When I tried rebuilding it on a Power G4 with
YellowDog installed on it, it complained that the
PowerPC host machine is not supported. Why is this
host architecture not supported? I also found out that
MontaVista does not support the PowerPC host
architecture anymore which they did a while ago. What
seems to be the real reason for not supporting this?
Thanks for the reply.
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: Kumar Gala @ 2005-01-14 15:54 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20050114155131.22836.qmail@web53809.mail.yahoo.com>
I'm guessing in the MV case it was cost vs demand.
- kumar
On Jan 14, 2005, at 9:51 AM, annamaya wrote:
> I noticed that ELDK from denx does not support running
> on a PowerPC host machine like the Power G4 or G5.
> When I tried rebuilding it on a Power G4 with
> YellowDog installed on it, it complained that the
> PowerPC host machine is not supported. Why is this
> host architecture not supported? I also found out that
> MontaVista does not support the PowerPC host
> architecture anymore which they did a while ago. What
> seems to be the real reason for not supporting this?
> Thanks for the reply.
>
>
>
> =A0=A0=A0=A0=A0=A0=A0
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Kernel 2.6.x to MPC8540/Microsys Board
From: Wolfgang Denk @ 2005-01-14 16:02 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <41E7D8F7.4060901@anagramm.de>
In message <41E7D8F7.4060901@anagramm.de> you wrote:
>
> >>Which is the best Kernel source tree to start porting 2.6.x to the pm854
> >>platform? I would prefer to stuck with the official sources. Is that a
> >>good idea?
> >
> > Yes.
>
> Thank you, that's what I wanted to hear :-)
Note that I didn't comment on using 2.6 in the first place.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
F u cn rd ths u cnt spl wrth a dm!
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: Wolfgang Denk @ 2005-01-14 16:07 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20050114155131.22836.qmail@web53809.mail.yahoo.com>
In message <20050114155131.22836.qmail@web53809.mail.yahoo.com> you wrote:
> I noticed that ELDK from denx does not support running
> on a PowerPC host machine like the Power G4 or G5.
> When I tried rebuilding it on a Power G4 with
> YellowDog installed on it, it complained that the
> PowerPC host machine is not supported. Why is this
Correct. PPC host are not supported yet. Also please not that only
RedHat-7.3 will work as a build host without additional tweaking.
> host architecture not supported? I also found out that
Little demand? We have seen less than 5 requests for this so far.
> MontaVista does not support the PowerPC host
> architecture anymore which they did a while ago. What
> seems to be the real reason for not supporting this?
Probably the same reason: little demand.
Well: the ELDK is free software - if you fix the existing build
problems and send me a patch I promise to check it in on the CVS
server (as long as it doesn't break anything). But don't expect this
to be an easy job.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If only God would give me some clear sign! Like making a large depo-
sit in my name at a Swiss Bank. - Woody Allen
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: annamaya @ 2005-01-14 16:16 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050114160743.74903C108D@atlas.denx.de>
Thanks for the reply Wolfgang. Can you give me a hint
on the kind of work that is required to make this work
for the PPC host?
--- Wolfgang Denk <wd@denx.de> wrote:
> In message
> <20050114155131.22836.qmail@web53809.mail.yahoo.com>
> you wrote:
> > I noticed that ELDK from denx does not support
> running
> > on a PowerPC host machine like the Power G4 or G5.
> > When I tried rebuilding it on a Power G4 with
> > YellowDog installed on it, it complained that the
> > PowerPC host machine is not supported. Why is this
>
> Correct. PPC host are not supported yet. Also please
> not that only
> RedHat-7.3 will work as a build host without
> additional tweaking.
>
> > host architecture not supported? I also found out
> that
>
> Little demand? We have seen less than 5 requests for
> this so far.
>
> > MontaVista does not support the PowerPC host
> > architecture anymore which they did a while ago.
> What
> > seems to be the real reason for not supporting
> this?
>
> Probably the same reason: little demand.
>
>
> Well: the ELDK is free software - if you fix the
> existing build
> problems and send me a patch I promise to check
> it in on the CVS
> server (as long as it doesn't break anything). But
> don't expect this
> to be an easy job.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime
> Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
> Email: wd@denx.de
> If only God would give me some clear sign! Like
> making a large depo-
> sit in my name at a Swiss Bank.
> - Woody Allen
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: Clemens Koller @ 2005-01-14 17:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050114161609.37891.qmail@web53805.mail.yahoo.com>
Hello, Annamaya
I am using a PPC Linux host here, too.
> Thanks for the reply Wolfgang. Can you give me a hint
> on the kind of work that is required to make this work
> for the PPC host?
Maybe you can save a lot of work using a mainstream Linux
distribution for PPC and install the gcc/gdb development as
you need it?!
If you need the ELDK root tree for booting from nfs
just copy the ppc_zyxx- folder over from the ELDK.
Just today, I needed to move to ppc without the ELDK as we
ran out of fast ix86 machines for compiling. I had to go
'back' to my PowerMac G4 which was my 'functional prototype'
for Linux driver development.
Right now (today) I didn't miss anything from the ELDK.
I use the 'CRUX PPC' distribution on that ppc-machine which
is really nice to use (no bells, no whistles).
If you want a fully fledged KDE/Gnome X, maybe you check out
the 'CRUX PPC Evolution' port.
The most painful part was to have the Mac Bootloader installed
to keep have 1x Linux, 2x MacOSX and 1x MacOS9 bootable on
that machine. :-) Maybe I should use U-Boot next time ;-)
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
> --- Wolfgang Denk <wd@denx.de> wrote:
>
>
>>In message
>><20050114155131.22836.qmail@web53809.mail.yahoo.com>
>>you wrote:
>>
>>>I noticed that ELDK from denx does not support
>>
>>running
>>
>>>on a PowerPC host machine like the Power G4 or G5.
>>>When I tried rebuilding it on a Power G4 with
>>>YellowDog installed on it, it complained that the
>>>PowerPC host machine is not supported. Why is this
>>
>>Correct. PPC host are not supported yet. Also please
>> not that only
>>RedHat-7.3 will work as a build host without
>>additional tweaking.
>>
>>
>>>host architecture not supported? I also found out
>>
>>that
>>
>>Little demand? We have seen less than 5 requests for
>>this so far.
>>
>>
>>>MontaVista does not support the PowerPC host
>>>architecture anymore which they did a while ago.
>>
>>What
>>
>>>seems to be the real reason for not supporting
>>
>>this?
>>
>>Probably the same reason: little demand.
>>
>>
>>Well: the ELDK is free software - if you fix the
>> existing build
>>problems and send me a patch I promise to check
>>it in on the CVS
>>server (as long as it doesn't break anything). But
>>don't expect this
>>to be an easy job.
>>
>>Best regards,
>>
>>Wolfgang Denk
>>
>>--
>>Software Engineering: Embedded and Realtime
>>Systems, Embedded Linux
>>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
>>Email: wd@denx.de
>>If only God would give me some clear sign! Like
>>making a large depo-
>>sit in my name at a Swiss Bank.
>> - Woody Allen
>>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-14 17:38 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEAECDDAAA.joakim.tjernlund@lumentis.se>
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > On Wed, Jan 12, 2005 at 08:15:08AM -0700, Tom Rini wrote:
> > > On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > > > > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > [snip]
> > > > > > Patch looks good to me, but I want to ask when this error
> > > > > > can be triggered in practice?
> > > > >
> > > > > It is possible to see this in the real world, as we (<hat=mvista>) found
> > > > > this with a customers app.
> > > >
> > > > hmm, this app must have been doing something pretty special. Any idea what
> > > > caused it?
> > >
> > > Only vaugely. I'll poke the folks who did the investigation to see if
> > > they recall (the app is quite large) and follow up with details, I hope.
> >
> > First, we couldn't get this issue to happen w/ anything but the custom
> > app. It would generate a lot of I-TLB Error exceptions, with bit 1 of
> > SRR1 set, and these went fine, the I-TLB got updated, and execution
> > continued. But then at some point, and we aren't sure why exactly, an
> > 0x1100 is generated, and we crash. We don't know what went and caused
> > an 0x1100 to be generated instead of an 0x1300 (my wild-ass-guess is the
> > code jumped very very far ahead).
>
> To me this looks like you entered the I-TLB Miss handler with a NULL pte which
> is something that never happens in my system, don't know why this is so but I am
> guessing that the kernel populates all instruction pte's at exec time. On the
> other hand I don't understand why there are so many I-TLB errors, is that normal?
>
> Does the app modify its own code or construct a code trampoline which it jumps to? Not
> sure how that would be handled by the kernel w.r.t NULL pte's
>
> Jocke
I think I have figured this out. The first TLB misses that happen at app startup is Data
TLB misses. These will then hit the NULL L1 entry and end up in do_page_fault() which
will populate the L1 entry. But when you have a very large app that spans more than one
L1 entry (16 MB I think) it may happen that you will have I-TLB Miss first one of the
L1 entrys which will make the I-TLB handler bail out to do_page_fault() and the app
craches(SEGV).
Your patch will fix this.
I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
Jocke
^ 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