* RE: kernel startup
From: atul.sabharwal @ 2006-02-10 23:53 UTC (permalink / raw)
To: galak, dibacco; +Cc: linuxppc-embedded
> Normally is it the uboot that uncompresses the kernel or the kernel
uncompress itself?=20
>>How would something compressed uncompress itself? If u-boot is being
used=20
>>it will uncompress a compressed kernel and put the image at physical
0.
Small correction. Just like a self extracting binary, a kernel can have
a decompression code prepended to the start of kernel which can
decompress the=20
Kernel. This is how redboot for xscale is structured or syslinux /lilo
for x86.=20
Although u-boot has simplified this step by doing the CRC checksum of
the
uiMage header as well as data and also decompress the kernel. Based on
load
address, entry point, the kernel can start executing. =20
Now, whether cache is enable or not, MMU is enabled/disabled depends on
the
Developer. In current u-boot, the MMU is not used. I-Cache is On and
D-cache
is off.
Best Regards,
Atul
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-10 23:46 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net>
> > Normally is it the uboot that uncompresses the kernel or the kernel
> uncompress itself?
>
> >>How would something compressed uncompress itself? If u-boot is being
> used
> >>it will uncompress a compressed kernel and put the image at physical
> 0.
>
> Small correction. Just like a self extracting binary, a kernel can have
> a decompression code prepended to the start of kernel which can
> decompress the
> Kernel. This is how redboot for xscale is structured or syslinux /lilo
> for x86.
This also happens with the boot wrapper that is in arch/{ppc,powerpc}/boot
>
> Although u-boot has simplified this step by doing the CRC checksum of
> the
> uiMage header as well as data and also decompress the kernel. Based on
> load
> address, entry point, the kernel can start executing.
>
> Now, whether cache is enable or not, MMU is enabled/disabled depends on
> the
> Developer. In current u-boot, the MMU is not used. I-Cache is On and
> D-cache
> is off.
I'm not sure what sub-arch we are talking about, but some do have the MMU
on.
- kumar
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:02 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
>>I'm not sure what sub-arch we are talking about, but some do have the
MMU=20
on.
I am using PPC 870 and u-boot 1.1.2. Which architecture should I look
for as a reference example. On my system, the RAM is not at address 0x0
but at
0x10000000. Since the exception table does not take full 32 bit address,
I am not sure how to tell the processor about the relocated location.
On this custom board with 870, is it necessary to have RAM at address
0x0
(or shadow it) or the 870 supports configuration for different base
addresses for memory. =20
Thanks,
Atul
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602101730210.31619-100000@gate.crashing.org>
In message <Pine.LNX.4.44.0602101730210.31619-100000@gate.crashing.org> you wrote:
>
> > What does it mean that the load address is 0x00000000?
>
> its the address u-boot's going to jump to and start executing kernel code
> from.
No. U-Boot will load (copy) the image to the load address but start
executing kernel code at the entry point address which may be
different.
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
"Am besten betrachten Sie Fehlermeldungen als eine Art Psycho-Test,
mit dem herausgefunden werden soll, wie belastbar Sie sind."
- Dr. R. Wonneberger, Kompaktführer LaTeX, Kap. 1.6: Fehlermeldungen
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:08 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net> you wrote:
>
> >>How would something compressed uncompress itself? If u-boot is being used
> >>it will uncompress a compressed kernel and put the image at physical 0.
>
> Small correction. Just like a self extracting binary, a kernel can have
> a decompression code prepended to the start of kernel which can decompress the
> Kernel. This is how redboot for xscale is structured or syslinux /lilo
No, this is not the kernel, but some additional component, often
called "bootstrap loader" or so, which wraps the kernel as payload in
it's own image.
> Now, whether cache is enable or not, MMU is enabled/disabled depends on the
> Developer. In current u-boot, the MMU is not used. I-Cache is On and D-cache
> is off.
This may be correct on some specific boards, but it's wrong on
others.
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
The existence of god implies a violation of causality.
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:10 UTC (permalink / raw)
To: atul.sabharwal, galak; +Cc: linuxppc-embedded
Since I have set IIP to 1, reset vector is at 0xfff00100. IMMR is
0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
at address 0x0 (ISA style).=20
As memory and internal processor registers would conflict, I would have
a memory hole. Hence, the logical choice of putting RAM at a different
location. So, if MMU allows shadowing (which I have not read), it could
solve my problem.
Regards,
Atul
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-11 0:03 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2084@us-bv-m23.global.tektronix.net>
On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:
> Since I have set IIP to 1, reset vector is at 0xfff00100. IMMR is
> 0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
> at address 0x0 (ISA style).
I'm not that familiar with 8xx, but can't you move IMMR?
- kumar
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:12 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2081@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2081@us-bv-m23.global.tektronix.net> you wrote:
>
> I am using PPC 870 and u-boot 1.1.2. Which architecture should I look
> for as a reference example. On my system, the RAM is not at address 0x0 but at
> 0x10000000. Since the exception table does not take full 32 bit address,
The phrase "the RAM is at address 0x10000000" is bogus.
The RAM "is" where you map it. The mapping is done in software. The
software is implementing your design.
In other words, your design is broken when you put the RAM at such a
strange adress instead of the natural location, starting from 0x0000.
> I am not sure how to tell the processor about the relocated location.
You don't; just fix your memory map.
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 God had a beard, he'd be a UNIX programmer.
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:19 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>The RAM "is" where you map it. The mapping is done in software. The
>>software is implementing your design.
>>In other words, your design is broken when you put the RAM at such a
>>strange address instead of the natural location, starting from 0x0000.
Memory is not on the local bus but across a third party memory
controller.
Two processors loosely coupled. So, the RAM is at non zero address.
This seems to be the critical problem in this design but need to
convince
the design engineers. I don't know the reason why they want memory at
non zero address but that's the requirement.
--
Atul
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:28 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
>>I'm not that familiar with 8xx, but can't you move IMMR?
Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
Or 0xFFF00000. =20
Flash is from 0xfe000000 thru 0xffffffff. Now on POR,
Processor goes to offset 0x100 on CS0. So, if IMMR is overlapping with
flash, it might not boot.
On 870, it seems that reset value for BR0/OR0 is undefined.
Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
Are remapped. So, I could put flash at a non-standard address like
0xDE000000 and move IMMR to 0xFF000000.
The problem this creates is that I can set IIP to 0 or 1. So, exception
Vector prefix can be 0 or 0xfff. Since no flash at 0xfff00000 base=20
Address I cannot have any exceptions in my code till the u-boot code
has relocated to RAM. Which should be acceptable as what can I do
if there is exception so early in the system.=20
Unless there is a better design ?
Thanks,
Atul
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-11 0:23 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2089@us-bv-m23.global.tektronix.net>
On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:
> >>I'm not that familiar with 8xx, but can't you move IMMR?
>
> Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
> Or 0xFFF00000.
>
> Flash is from 0xfe000000 thru 0xffffffff. Now on POR,
> Processor goes to offset 0x100 on CS0. So, if IMMR is overlapping with
> flash, it might not boot.
>
> On 870, it seems that reset value for BR0/OR0 is undefined.
> Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
> Are remapped. So, I could put flash at a non-standard address like
> 0xDE000000 and move IMMR to 0xFF000000.
>
> The problem this creates is that I can set IIP to 0 or 1. So, exception
> Vector prefix can be 0 or 0xfff. Since no flash at 0xfff00000 base
> Address I cannot have any exceptions in my code till the u-boot code
> has relocated to RAM. Which should be acceptable as what can I do
> if there is exception so early in the system.
>
> Unless there is a better design ?
It sounds like you should move this discussion to the u-boot list since it
has very little to do with the kernel.
- k
^ permalink raw reply
* Re: Flattened device tree for Pegasos
From: Kumar Gala @ 2006-02-11 0:46 UTC (permalink / raw)
To: Mark A. Greer, Benjamin Herrenschmidt, Paul Mackerras,
Segher Boessenkool
Cc: linuxppc-dev
In-Reply-To: <20060211004814.GB22539@mag.az.mvista.com>
On Fri, 10 Feb 2006, Mark A. Greer wrote:
> If anyone happens to have a Pegasos running the merged powerpc kernel
> handy, I would greatly appreciate a dump of flattened device tree that
> it uses.
We really need to put OF tree's somewhere that people can get to, maybe
penguinppc.org.
Ben, Segher, Paul:
You guys have either access to HW or tree dump's already. Would you be
willing to share them?
- kumar
^ permalink raw reply
* Flattened device tree for Pegasos
From: Mark A. Greer @ 2006-02-11 0:48 UTC (permalink / raw)
To: linuxppc-dev
If anyone happens to have a Pegasos running the merged powerpc kernel
handy, I would greatly appreciate a dump of flattened device tree that
it uses.
Thanks,
Mark
^ permalink raw reply
* Re: Flattened device tree for Pegasos
From: Mark A. Greer @ 2006-02-11 0:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.44.0602101844150.31619-100000@gate.crashing.org>
On Fri, Feb 10, 2006 at 06:46:59PM -0600, Kumar Gala wrote:
> On Fri, 10 Feb 2006, Mark A. Greer wrote:
>
> > If anyone happens to have a Pegasos running the merged powerpc kernel
> > handy, I would greatly appreciate a dump of flattened device tree that
> > it uses.
>
> We really need to put OF tree's somewhere that people can get to, maybe
> penguinppc.org.
>
> Ben, Segher, Paul:
>
> You guys have either access to HW or tree dump's already. Would you be
> willing to share them?
/me seconds that request.
Mark
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 1:12 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2084@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2084@us-bv-m23.global.tektronix.net> you wrote:
> Since I have set IIP to 1, reset vector is at 0xfff00100. IMMR is
> 0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
> at address 0x0 (ISA style).
Please do yourself a favour and read some docs and FAQ's first. With
a low mapping ogf the IMMR like 0x00f00000 you will never be able to
run Linux.
And as mentioned before: the whole memory map is just software. If it
doesn't fit your needs just change it.
> As memory and internal processor registers would conflict, I would have
Then CHANGE it! It's just a few bits in some registers.
> a memory hole. Hence, the logical choice of putting RAM at a different
This is not a logical choice, but just another error.
> location. So, if MMU allows shadowing (which I have not read), it could
> solve my problem.
Please forget it. Just fix your memory map.
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
Why don't you have a Linux partition installed so you can be working
in a programmer-friendly environment instead of a keep-gates'-bank-
account-happy one? :-) -- Tom Christiansen
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 1:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: atul.sabharwal, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602101802590.31619-100000@gate.crashing.org>
In message <Pine.LNX.4.44.0602101802590.31619-100000@gate.crashing.org> you wrote:
>
> I'm not that familiar with 8xx, but can't you move IMMR?
Of course you can.
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
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 1:20 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2089@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2089@us-bv-m23.global.tektronix.net> you wrote:
>
> Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
> Or 0xFFF00000.
Initially. But you can change it.
> Flash is from 0xfe000000 thru 0xffffffff. Now on POR,
> Processor goes to offset 0x100 on CS0. So, if IMMR is overlapping with
> flash, it might not boot.
Just fix your memory map.
> On 870, it seems that reset value for BR0/OR0 is undefined.
Please RTFM. The steps how the processor comes up from reset are
documented in great detail. Especially the handling of the boot
device chip select.
> Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
> Are remapped. So, I could put flash at a non-standard address like
> 0xDE000000 and move IMMR to 0xFF000000.
There is no such thing as a "non-standard" address, as there is no
"standard" address either.
> The problem this creates is that I can set IIP to 0 or 1. So, exception
> Vector prefix can be 0 or 0xfff. Since no flash at 0xfff00000 base
> Address I cannot have any exceptions in my code till the u-boot code
> has relocated to RAM. Which should be acceptable as what can I do
> if there is exception so early in the system.
In most cases it is useful to configure a system for low-boot, i. e.
let it start at 0x0100. Then just set up your memory map as you
like...
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
You don't need a weatherman to know which way the wind blows.
- Bob Dylan
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 1:40 UTC (permalink / raw)
To: wd, galak; +Cc: linuxppc-embedded
> I'm not that familiar with 8xx, but can't you move IMMR?
Of course you can.
That's correct but on 8540, it did not work. I was using u-boot
And BDI had mapped it to 0xe0000000 and u-boot had mapped it to
0x40000000. So, it was a problem as serial interface did not work.
It was easier to keep IMMR value same in the BDI configuration and the
processor. Just did not find it necessary to relocate it.
Most of the time, it's a question between conceptual and factual(does it
work ?).
--
Atul
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 1:47 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>Please do yourself a favour and read some docs and FAQ's first. With
>>a low mapping ogf the IMMR like 0x00f00000 you will never be able to
>>run Linux.
I know that the processor does not allow setting up a base address for
the
exception vectors. In this situation, it would never be able to handle
TLB or system call exceptions. =20
Just don't know if this is feasible so scrambling for any other docs. I
have the instruction reference and development manual.
Seems to be a bad requirement to not have RAM at address 0x0. Would have
to change that. Rest should just fall in place by booting low. This
would allow exception handling from flash as well as RAM.
Best Regards,
Atul
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 2:03 UTC (permalink / raw)
To: atul.sabharwal, wd; +Cc: linuxppc-embedded
Actually, it would be great if PPC would allow the exception handlers to
execute from DPRAM. The handler would run faster than coming from a
RAM/flash or some EEPROM. Don't know all the implications but should be
a useful speedup.
--
Atul
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 2:10 UTC (permalink / raw)
To: atul.sabharwal, wd; +Cc: linuxppc-embedded
More efficient would be to lock the exception handlers in L1 cache. I
don't know the access rate of DPRAM on 870? Should be bus speed? So,
DPRAM and external memory would be same access time unless the
electrical characteristics of RAM vs. DPRAM technology is different.
--
Atul
^ permalink raw reply
* Kernel Crash
From: Jayaprakash Shanmugam @ 2006-02-11 5:37 UTC (permalink / raw)
To: linuxppc-embedded
Hello Everyone,
I am using MPC 8270 based board with 2.6. It crashes at times.=20
Mostly it is related to timers. I have attached several crash reports
here. Anybody can give me some pointers on what could be wrong ? I
really appreciate your help. Thanks.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C00288C0 LR: C00289FC SP: CF493C80 REGS: cf493bd0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0018F24 LR: C001A174 SP: CF415E90 REGS: cf415de0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00C15C74, DSISR: 22000000
TASK =3D c05d7b30[549] 'CCMsgHndlrExe' THREAD: cf414000
Last syscall: 104
GPR00: 00000078 CF415E90 C05D7B30 C05D7B30 C02858AC 2800046C 00000000 C0285=
8B0
GPR08: 00C15C74 00000001 C05D7B50 0000008C B4868000 1003811C 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
668
GPR24: C0290000 C0280000 C02820A8 C0280000 00000000 C0285400 C05D7B30 CF415=
E90
NIP [c0018f24] enqueue_task+0x34/0x7c
LR [c001a174] scheduler_tick+0x300/0x360
Call trace:
[c0019c18] account_user_time+0x78/0xe8
[c002924c] update_process_times+0x98/0x150
[c0005504] timer_interrupt+0x88/0x22c
[c000448c] ret_from_except+0x0/0x14
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C013CAF8 LR: C013CCC4 SP: C06FDCA0 REGS: c06fdbf0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00C12048, DSISR: 20000000
TASK =3D c05d7b30[495] 'CCMsgHndlrExe' THREAD: c06fc000
Last syscall: 54
GPR00: 00000001 C06FDCA0 C05D7B30 CF64F0F0 CFAF0000 0004DC93 C0280000 C028A=
C8C
GPR08: 00200200 00C12000 00C12048 CF64F0F0 2010C022 1003811C 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
668
GPR24: C0290000 00000001 00000000 CF64F000 CFAF0000 CF64F0F0 00001032 CF64F=
000
NIP [c013caf8] roothub_a+0xc/0x6c
LR [c013ccc4] ohci_hub_status_data+0xa4/0x1a8
Call trace:
[c0130978] rh_report_status+0x12c/0x164
[c0029460] run_timer_softirq+0x120/0x228
[c0024068] __do_softirq+0xd0/0xd8
[c00240c8] do_softirq+0x58/0x5c
[c002419c] irq_exit+0x54/0x58
[c0005668] timer_interrupt+0x1ec/0x22c
[c000448c] ret_from_except+0x0/0x14
[d106f5a8] FD_ioctl+0x2160/0x35a8 [FDAC1]
[c007375c] do_ioctl+0x84/0xac
[c00739e8] vfs_ioctl+0x88/0x2c8
[c0073c6c] sys_ioctl+0x44/0x78
[c0003de0] ret_from_syscall+0x0/0x44
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Oops: kernel access of bad are
a, sig: 11 [#1]
PREEMPT
NIP: C0018F24 LR: C001A174 SP: CF415E90 REGS: cf415de0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00C15C74, DSISR: 22000000
TASK =3D c05d7b30[549] 'CCMsgHndlrExe' THREAD: cf414000
Last syscall: 104
GPR00: 00000078 CF415E90 C05D7B30 C05D7B30 C02858AC 2800046C 00000000 C0285=
8B0
GPR08: 00C15C74 00000001 C05D7B50 0000008C B4868000 1003811C 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
668
GPR24: C0290000 C0280000 C02820A8 C0280000 00000000 C0285400 C05D7B30 CF415=
E90
NIP [c0018f24] enqueue_task+0x34/0x7c
LR [c001a174] scheduler_tick+0x300/0x360
Call trace:
[c0019c18] account_user_time+0x78/0xe8
[c002924c] update_process_times+0x98/0x150
[c0005504] timer_interrupt+0x88/0x22c
[c000448c] ret_from_except+0x0/0x14
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0018F24 LR: C001A150 SP: CF415D70 REGS: cf415cc0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00C1580C, DSISR: 22000000
TASK =3D c0525b30[495] 'CCMsgHndlrExe' THREAD: cf414000
Last syscall: 54
GPR00: 00000000 CF415D70 C0525B30 C0525B30 C0285434 00000001 100300EA C0285=
438
GPR08: 00C1580C 00000001 C0525B50 00000076 DB718800 1003807C 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
5C8
GPR24: C0290000 C0280000 C02820A8 C0280000 00000000 C0285400 C0525B30 CF415=
D70
NIP [c0018f24] enqueue_task+0x34/0x7c
LR [c001a150] scheduler_tick+0x2dc/0x360
Call trace:
[c0019cf0] account_system_time+0x68/0x144
[c002924c] update_process_times+0x98/0x150
[c0005504] timer_interrupt+0x88/0x22c
[c000448c] ret_from_except+0x0/0x14
[c00739e0] vfs_ioctl+0x80/0x2c8
[c0073c6c] sys_ioctl+0x44/0x78
[c0003de0] ret_from_syscall+0x0/0x44
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0018F24 LR: C001A150 SP: CF415D70 REGS: cf415cc0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00C1580C, DSISR: 22000000
TASK =3D c0525b30[495] 'CCMsgHndlrExe' THREAD: cf414000
Last syscall: 54
GPR00: 00000000 CF415D70 C0525B30 C0525B30 C0285434 00000001 100300EA C0285=
438
GPR08: 00C1580C 00000001 C0525B50 00000076 DB718800 1003807C 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
5C8
GPR24: C0290000 C0280000 C02820A8 C0280000 00000000 C0285400 C0525B30 CF415=
D70
NIP [c0018f24] enqueue_task+0x34/0x7c
LR [c001a150] scheduler_tick+0x2dc/0x360
Call trace:
[c0019cf0] account_system_time+0x68/0x144
[c002924c] update_process_times+0x98/0x150
[c0005504] timer_interrupt+0x88/0x22c
[c000448c] ret_from_except+0x0/0x14
[c00739e0] vfs_ioctl+0x80/0x2c8
[c0073c6c] sys_ioctl+0x44/0x78
[c0003de0] ret_from_syscall+0x0/0x44
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Uninitialised timer!
This is just a warning. Your computer is OK
function=3D0xc013084c, data=3D0xcfa7e1a0
Call trace:
[c0006d48] dump_stack+0x18/0x28
[c0028824] check_timer_failed+0x7c/0x80
[c0028bc8] mod_timer+0x40/0x8c
[c01309ac] rh_report_status+0x160/0x164
[c0029460] run_timer_softirq+0x120/0x228
[c0024068] __do_softirq+0xd0/0xd8
[c00240c8] do_softirq+0x58/0x5c
[c002419c] irq_exit+0x54/0x58
[c0005668] timer_interrupt+0x1ec/0x22c
[c000448c] ret_from_except+0x0/0x14
[d106d50c] FD_ioctl+0xc4/0x35a8 [FDAC1]
[c007375c] do_ioctl+0x84/0xac
[c00739e8] vfs_ioctl+0x88/0x2c8
[c0073c6c] sys_ioctl+0x44/0x78
[c0003de0] ret_from_syscall+0x0/0x44
Uninitialised timer!
This is just a warning. Your computer is OK
function=3D0xc013084c, data=3D0xcfa7e1a0
Call trace:
[c0006d48] dump_stack+0x18/0x28
[c0028824] check_timer_failed+0x7c/0x80
[c0028bc8] mod_timer+0x40/0x8c
[c01309ac] rh_report_status+0x160/0x164
[c0029460] run_timer_softirq+0x120/0x228
[c0024068] __do_softirq+0xd0/0xd8
[c00240c8] do_softirq+0x58/0x5c
[c002419c] irq_exit+0x54/0x58
[c0005668] timer_interrupt+0x1ec/0x22c
[c000448c] ret_from_except+0x0/0x14
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C00293DC LR: C0029384 SP: CF449D50 REGS: cf449ca0 TRAP: 0300 Not ta=
inted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0A8324AC, DSISR: 22000000
TASK =3D c05d7b30[549] 'CCMsgHndlrExe' THREAD: cf448000
Last syscall: 54
GPR00: 000AF4C4 CF449D50 C05D7B30 00000001 64F56640 000AF4C3 C0280000 C028A=
E0C
GPR08: C028AE14 CF449D60 CFB224AC 0A8324AC D5990000 10038490 0FFF8000 00000=
000
GPR16: 00000001 7FFFFB30 10016EB9 00000001 00000000 1001751C 10001694 1000E=
734
GPR24: C0290000 C0290000 C0200000 C028A7F4 CF449D60 C028C044 C028A608 00000=
0C3
NIP [c00293dc] run_timer_softirq+0x9c/0x228
LR [c0029384] run_timer_softirq+0x44/0x228
Call trace:
[c0024068] __do_softirq+0xd0/0xd8
[c00240c8] do_softirq+0x58/0x5c
[c002419c] irq_exit+0x54/0x58
[c0005668] timer_interrupt+0x1ec/0x22c
[c000448c] ret_from_except+0x0/0x14
[c00739b8] vfs_ioctl+0x58/0x2c8
[c0073c6c] sys_ioctl+0x44/0x78
[c0003de0] ret_from_syscall+0x0/0x44
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
Thanks & Regards,
Jayaprakash.
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 6:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060210173133.964B53525CC@atlas.denx.de>
Hi Wolfgang,
>>Of course there is also the option of finding another
>>PowerPC that matches my requirements;
> ...
> MPC834x comes to mind. But I have to admit that we never tried using
> this as a PCI device yet...
Indeed you were correct. The MPC834x series meets my requirements.
It is also a 3.3V PCI device, so I'm checking into whether
the Trenton CPUs I can use as host CPUs use a 3.3V PCI interface.
If that is the case, then I'll move the Force CPUs into another
system, and I'll just define the cPCI bus in the correlator
system as 3.3V-only.
The potential advantages of the MPC834x over the 440EP are;
- it has doorbell registers and mailboxes for PCI
host-to-host comms (though does not have an I2O interface)
- its DDR-SDRAM controller can run faster than the 440EP
- its external local bus is wider and faster than
the 440EP
- but I think the MPC834x internal buses are slower than
the 440EP CoreConnect buses, so I'll need to benchmark
to compare the two.
- it exists! I can find them on distributors web sites
(can't say the same for the 440EP yet!)
So, I'll continue with my evalation of the 440EP, and then
I'll want to evaluate the MPC834x devices.
What MPC834x development kit are you using? What would you recommend?
- I'd like to get a board in a PCI or cPCI-form factor, since
I could use it as a PCI agent/peripheral
- I'd really like to get access to the external bus
too.
Embedded Planet has a PrPMC module with an 8343E, but I doubt
I can get to the local bus on that board. I found news releases
of an MPC8349E QUICCstart board, but couldn't find anything
on Freescale's web site. Wind River appears to have an eval
board; SBC8347E/49E, which looks to be a cPCI board, but their
web site didn't have much in the way of details (or pictures).
Freescale do have the MPC8349EMDS 'MPC8349E Modular Development
System', but its not clear how much of that system I would
need to purchase just to test the board in a PCI system.
Looks like its aimed toward AdvancedTCA development.
Anyway, thanks for the pointer to the MPC834x series!
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 6:06 UTC (permalink / raw)
To: Mark Chambers, linuxppc-embedded
In-Reply-To: <001701c62e6c$09c48ea0$6401a8c0@CHUCK2>
Hi Mark,
> I'm currently working on an MPC8247 based design, btw.
> It has a PC104+ header and is directly connected to a
> T.I. 6205 (which, at $10, is a lot of crunch for the buck).
I took a look at the MPC8727 family.
The CPM runs at 200MHz max, and the SSCs can clock at
1/4 that, so only 50MHz; 50MHz/8-bits = 6MB/s.
They're too slow to move 132MB/s.
There is only two external buses too, and no
external bus to memory DMA, since they are the
same bus.
Also, the MPC834x series exists, and beats it out
performance wise.
Thanks for the pointer though!
Dave
^ permalink raw reply
* accessing serial port of MPC860T
From: bharathi kandimalla @ 2006-02-11 6:37 UTC (permalink / raw)
To: jagadish, linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Hi
I am able to open the scc2 port from the user space application
but I am not able to write to the device.
I think write function is not implemented correctly
even if I wrote code for write function in the file
cpm_uart_cpm1.c it is effecting console port
As the code comes from the linux 2.6.13 for the
Mpc860T works correctly? /or it requires some modifications to work properly
If the port (SMC2 OR SCC1 OR SMC] is configured as the CONSOLE it is working fine
best regards
BHARATHI
---------------------------------
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
[-- Attachment #2: Type: text/html, Size: 905 bytes --]
^ 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