[Newbie] Question on m8260_gorom
From: Srivatsan CR <hidden>
Date: 2005-08-08 13:18:39
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: linuxppc-embedded-request@ozlabs.org
[mailto:linuxppc-embedded-request@ozlabs.org]
Sent: Monday, August 08, 2005 7:19 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 12, Issue 25
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@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@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@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 <redacted>
Subject: Re: [PATCH] 8xx: add cpm_get_cpmp()
To: Marcelo Tosatti <redacted>
Cc: linuxppc-embedded@ozlabs.org
Message-ID: [ref]
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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Aristeu Sergio Rozanski Filho <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Dan Malek <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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:quoted
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.
quoted
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" <redacted> Subject: A configure error for samba3 on ppc To: <redacted> Message-ID: [ref] 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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Marcelo Tosatti <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Dan Malek <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Aristeu Sergio Rozanski Filho <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] Content-Type: text/plain; charset=us-ascii On Sun, Aug 07, 2005 at 12:44:32PM -0300, Aristeu Sergio Rozanski Filho wrote:
quoted
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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Aristeu Sergio Rozanski Filho <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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 <redacted> Subject: Re: [PATCH] 8xx: add cpm_get_cpmp() To: Marcelo Tosatti <redacted> Cc: linuxppc-embedded@ozlabs.org Message-ID: [ref] 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:
quoted
quoted
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" <redacted> Subject: Re: Volunteers to test i2c-algo-8xx on v2.6? To: "Marcelo Tosatti" <redacted> Cc: Linuxppc-embedded <redacted> Message-ID: [ref] Hello, Marcelo Tosatti In message <2005-08-07 08:34:52 marcelo.tosatti@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@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@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@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-08
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 12, Issue 25
*************************************************