Dear all,
1) I am using a LinuxPPC kernel version 2.4.18 and on a MPC8280
processor.
2) I am assuming that the Linux memory map for PowerPC looks like the
following:
END_OF_RAM|---------------|
| |
| |
| |
| |
| |
| |
0x800000|---------------|
|Linux-PPC |
|Kernel |
| |
0x0 |---------------|
Even at the run-time the kernel code resides in the Ram from address 0x0
till 8MB. In m8260_gorom the start_addr variable is initialized to 0x0 but
Kernel is not booting. Actually we are trying to boot the Linux Kernel from
its RAM copy at the time of exception.
3) An Kernel stack overflow was generated . So that the control enters
m8260_gorom. On entering m8260_gorom it executes till RFI after that the
control gets inside my_console_write. This happens even before we execute
the mtlr r4 and blr opcodes. So something else is creating the exception
which is making the code to dump exception on the console. (Not sure what it
is?)
4) Questions are :
a) Is it possible to start from Ram copy of the Linux kernel
Image at an exception generated restart
mechanism ?
B) Has anyone encountered a situation like the one described
above and can anyone tell us what is the cause
of the exception. (It's always printing "Bad kernel page
access")
Thanks for all your time.
With Best Regards,
C.R.Srivatsan
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-request at ozlabs.org]
Sent: Monday, August 08, 2005 7:19 AM
To: linuxppc-embedded at ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 12, Issue 25
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded at ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request at ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner at ozlabs.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
2. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
3. Re: [PATCH] 8xx: add cpm_get_cpmp() (Marcelo Tosatti)
4. A configure error for samba3 on ppc (JohnsonCheng)
5. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
6. Re: [PATCH] 8xx: add cpm_get_cpmp()
(Aristeu Sergio Rozanski Filho)
7. Re: [PATCH] 8xx: add cpm_get_cpmp() (Marcelo Tosatti)
8. Re: [PATCH] 8xx: add cpm_get_cpmp() (Dan Malek)
9. Re: [PATCH] 8xx: add cpm_get_cpmp() (Eugene Surovegin)
10. Re: Volunteers to test i2c-algo-8xx on v2.6? (Debora Liu)
----------------------------------------------------------------------
Message: 1
Date: Sat, 6 Aug 2005 22:40:37 -0400
From: Dan Malek <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti at cyclades.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <e5caa80a2cd721a4f6ee3c74ead906b2 at embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote:
> It already is exported, declared as
>
> commproc.h:extern cpm8xx_t *cpmp; /* Pointer to
> comm processor */
>
>
> and many drivers use the pointer directly.
We shouldn't be doing this. All drivers should ioremap() any peripheral
spaces they use and not make any assumptions someone else has done that
already. We've been making such changes in the 82xx/83xx/85xx CPM2 drivers.
If it isn't convenient to find the #defines for the ioremap(), we should
change that. When I originally wrote all of this code, it was long ago when
we didn't have some of the abstractions and it seemed any shortcuts for
performance were desired :-)
> arch/ppc/8260_io/ drivers also use the same convention.
If there are any drivers in here, they either aren't used or on their way
out. The only things that should remain are common support functions.
Thanks.
-- Dan
------------------------------
Message: 2
Date: Sat, 6 Aug 2005 23:36:16 -0400
From: Dan Malek <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <d74e24bbf82e4cedd3358465343d28ae at embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 6, 2005, at 7:42 PM, Aristeu Sergio Rozanski Filho wrote:
> but not with EXPORT_SYMBOL(). I noticed this while compiling i2c stuff
> as module. also, I think it's better add a function to do this instead
> doing EXPORT_SYMBOL() in a variable.
Right. We should just ioremap() :-)
Thanks.
-- Dan
------------------------------
Message: 3
Date: Sun, 7 Aug 2005 01:31:10 -0300
From: Marcelo Tosatti <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Dan Malek <dan at embeddededge.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <20050807043110.GA6316 at dmt.cnet>
Content-Type: text/plain; charset=us-ascii
On Sat, Aug 06, 2005 at 10:40:37PM -0400, Dan Malek wrote:
>
> On Aug 6, 2005, at 7:27 PM, Marcelo Tosatti wrote:
>
> >It already is exported, declared as
> >
> >commproc.h:extern cpm8xx_t *cpmp; /* Pointer to
> >comm processor */
> >
> >
> >and many drivers use the pointer directly.
>
> We shouldn't be doing this. All drivers should ioremap() any
> peripheral spaces they use and not make any assumptions someone else
> has done that already. We've been making such changes in the
> 82xx/83xx/85xx CPM2 drivers. If it isn't convenient to find the
> #defines for the ioremap(), we should change that. When I originally
> wrote all of this code, it was long ago when we didn't have some of
> the abstractions and it seemed any shortcuts for performance were
> desired :-)
OK makes sense (yep it was even discussed already).
Aris, sounds like you should proceed with cpm_get_cpmp() and change all
other drivers using it also.
>
>
> >arch/ppc/8260_io/ drivers also use the same convention.
>
> If there are any drivers in here, they either aren't used or on their
> way out. The only things that should remain are common support
> functions.
OK!
------------------------------
Message: 4
Date: Sun, 7 Aug 2005 17:15:55 +0800
From: "JohnsonCheng" <[EMAIL PROTECTED]>
Subject: A configure error for samba3 on ppc
To: <linuxppc-embedded at ozlabs.org>
Message-ID: <20050807091603.CE57667F29 at ozlabs.org>
Content-Type: text/plain; charset="us-ascii"
When I configure samba3.0.10 on ppc as following command:
CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib
./configure -host=powerpc-linux
I got a configure error message as following:
Configure: error: cannot run test program while cross compiling
See 'config.log' for more details
I think this is a samba configure bug, do anybody know how to pass it?
Thanks,
Johnson Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050807/95f23597/
attachment-0001.htm
------------------------------
Message: 5
Date: Sun, 7 Aug 2005 11:39:52 -0400
From: Dan Malek <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti at cyclades.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <09b0792f426f1d5883cf5d437723f075 at embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 7, 2005, at 12:31 AM, Marcelo Tosatti wrote:
> Aris, sounds like you should proceed with cpm_get_cpmp() and change
> all other drivers using it also.
It depends how you define the semantics of this function call.
Can you call it any (and all of the) time you need it, or does it actually
perform an ioremap() and you only want to call it once?
I guess implemented properly it doesn't matter. On the first call it should
do the ioremap() and on subsequent calls it just returns the mapping. This
is one of those common functions that should be in commproc.c.
Thanks.
-- Dan
------------------------------
Message: 6
Date: Sun, 7 Aug 2005 12:44:32 -0300
From: Aristeu Sergio Rozanski Filho <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Dan Malek <dan at embeddededge.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <20050807154432.GE5210 at cathedrallabs.org>
Content-Type: text/plain; charset=us-ascii
> It depends how you define the semantics of this function call.
> Can you call it any (and all of the) time you need it, or does it
> actually perform an ioremap() and you only want to call it once?
what about don't cache it and call ioremap() from driver? (I guess
ioremap() already check if an area is already mapped, no?)
--
Aristeu
------------------------------
Message: 7
Date: Sun, 7 Aug 2005 12:57:31 -0300
From: Marcelo Tosatti <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <20050807155731.GA2715 at dmt.cnet>
Content-Type: text/plain; charset=us-ascii
On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho
wrote:
> > It depends how you define the semantics of this function call.
> > Can you call it any (and all of the) time you need it, or does it
> > actually perform an ioremap() and you only want to call it once?
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Yep, ioremap() should be doing virtual address caching already, no?
------------------------------
Message: 8
Date: Sun, 7 Aug 2005 13:25:34 -0400
From: Dan Malek <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Aristeu Sergio Rozanski Filho <aris at cathedrallabs.org>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <2fcd8a329246b2f2c303e515dd0cb7bf at embeddededge.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Aug 7, 2005, at 11:44 AM, Aristeu Sergio Rozanski Filho wrote:
> what about don't cache it and call ioremap() from driver? (I guess
> ioremap() already check if an area is already mapped, no?)
Either way. I'm actually leaning toward these "pointer helper"
functions. :-) Something like get_cpmp(), or get_immr(), that will hide the
details of the mapping, so you don't have to include and know which #defines
to use as part of an ioremap() call.
It seems to be more clear to me, and I'm thinking about making the same
changes to the CPM2 drivers. It also allows a performance versus compact
code trade off, declaring these as inline functions or as real functions.
Thanks.
-- Dan
------------------------------
Message: 9
Date: Sun, 7 Aug 2005 12:18:29 -0700
From: Eugene Surovegin <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <marcelo.tosatti at cyclades.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <20050807191829.GA5375 at gate.ebshome.net>
Content-Type: text/plain; charset=us-ascii
On Sun, Aug 07, 2005 at 12:57:31PM -0300, Marcelo Tosatti wrote:
> On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho
wrote:
> > > It depends how you define the semantics of this function call.
> > > Can you call it any (and all of the) time you need it, or does it
> > > actually perform an ioremap() and you only want to call it once?
> > what about don't cache it and call ioremap() from driver? (I guess
> > ioremap() already check if an area is already mapped, no?)
>
> Yep, ioremap() should be doing virtual address caching already, no?
In general, ioremap() doesn't do any caching currently. Some subarchs do
some limited caching, e.g. if BATs (classic PPC) or CAMs (e500) are
available and were used previously for ioremap() mappings.
Some time ago I made a trivial ioremap cache patch (useful on 4xx, which
doesn't have BATs nor CAMs), although it wass really a hack and it was never
merged :).
--
Eugene
------------------------------
Message: 10
Date: Mon, 8 Aug 2005 09:53:32 +0800
From: "Debora Liu" <[EMAIL PROTECTED]>
Subject: Re: Volunteers to test i2c-algo-8xx on v2.6?
To: "Marcelo Tosatti" <marcelo.tosatti at cyclades.com>
Cc: Linuxppc-embedded <Linuxppc-embedded at ozlabs.org>
Message-ID: <20050808014920.0373467F1E at ozlabs.org>
Hello, Marcelo Tosatti
In message <2005-08-07 08:34:52 marcelo.tosatti at cyclades.com> you wrote:
>
>Does anyone volunteer to test this 8xx i2c driver?
>
>
I don't have kernel v2.6, but I have test my board with eldk-3.1.1
linux-2.4.25
when my board kernel booting, I found one problem.
eldk-3.1.1 linux-2.4.25 kernel include i2c, i2c-algo-8xx, pcf8563 driver.
If one pcf8563 chip on my board, there are't problem.
But if my board don't have pcf8563 chip, kernel stop as blow:
Linux version 2.4.25 (liu at bighead) (gcc version 3.3.3 (DENX ELDK 3.1.1
3.3.3-9))
#4 ?? 7?? 29 12:19:14 CST 2005
m8xx_setup.c:Reserved 0x10000 memory at 0xc0190000
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nftla1
ip=192.168.0.207:192.168.0.82:::sc855t:eth
0:off
Decrementer Frequency = 300000000/60
Warning: real time clock seems stuck!
Calibrating delay loop... 79.66 BogoMIPS
========= HZ=100 loops_per_jiffy=398336
Memory: 30752k available (1144k kernel code, 356k data, 56k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
WDT_8xx: SWT not enabled by firmware, SYPCR=0xffffff88
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.1 (20010830)
i2c-rpx.o: i2c MPC8xx module version 2.6.1 (20010830)
i2c-proc.o version 2.6.1 (20010830)
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd at denx.de
I modify i2c-algo-8xx.c cpm_iic_write(), then no problem,
my board defined by CONFIG_SVM8xx
#ifdef CONFIG_SVM8xx
while(!(i2c->i2c_i2cer & 0x12))
if (time_after(jiffies, tmo)) {
tmo = 0;
break;
}
#else
while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo)));
/* Bus
#endif
= = = = = = = = = = = = = = = = = = = =
????????????????Debora Liu
????????????????deboralh at fel.com.cn
????????????????????2005-08-08
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 12, Issue 25
*************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050808/cc29bd35/attachment.htm
