* 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
* linux 2.6.13 URL
From: bharathi kandimalla @ 2006-02-11 6:48 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi
I want to download the linux 2.6.13 as I am using it
But I did not find it source code at
http://www.kernel.org/
As I have find all other different versions 2.6,15
2.6.16 ..
where can I download linux 2.6.13?
will you please give me the URL?
best regards
Bharathi
---------------------------------
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
[-- Attachment #2: Type: text/html, Size: 676 bytes --]
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-11 8:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ECD753.5000105@ovro.caltech.edu>
Hi David,
On Friday 10 February 2006 19:11, David Hawkins wrote:
> > Just use newer host CPU's! ;-)
>
> Ah, the words of a true engineer :)
>
> Of course the project manager wouldn't appreciate me doing that.
>
> However, its not totally out of the question ... $50 per 21555
> and 20 per crate, thats $1000, about half the price of
> a CPU. But of course, without the I20 unit on the 440EP,
> I might need the 21555 anyway.
Do you really need this I2O unit? You could easily create some message
ringbuffers, one in the 440EP's SDRAM for the host-to-440 messages and one in
the host-cpu SDRAM for the 440-to-host messages. This way, all messages will
be transferred using pci writes.
Best regards,
Stefan
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-11 8:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ED7E1E.2030700@ovro.caltech.edu>
Hi David,
On Saturday 11 February 2006 07:03, David Hawkins wrote:
> 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.
Ahhh. ;-)
> 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!)
Hmmm. The 440EP is around for quite a while. I would be surprised if you
couldn't buy those parts right now. But I have to admit, I never tried to. I
would contact my AMCC distributor for availability...
Best regards,
Stefan
^ permalink raw reply
* [PATCH] ppc64: poison invalid cpus
From: Anton Blanchard @ 2006-02-11 11:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060210140008.GA11864@suse.de>
Ensure that per cpu access to !possible cpus causes a fault instead of silent
corruption.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Olaf Hering <olh@suse.de>
---
Thanks Olaf, I had forgotten to send it out.
Index: linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.16-rc1-git3.orig/arch/powerpc/kernel/setup_64.c
+++ linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
@@ -670,6 +670,14 @@ void __init setup_per_cpu_areas(void)
size = PERCPU_ENOUGH_ROOM;
#endif
+ /*
+ * Poison invalid cpus, with lots of high bits set this should
+ * always fault
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ paca[i].data_offset = 0xeeeeeeeeeeeeeeeeULL;
+ }
+
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 12:59 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA209B@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA209B@us-bv-m23.global.tektronix.net> you wrote:
> >>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
This has nothing to do with that. Please *read* the FAQ!
> Just don't know if this is feasible so scrambling for any other docs. I
> have the instruction reference and development manual.
You can reinvent the wheel, or read the documented experience of
others who went the same way long time ago.
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 perversity of nature is nowhere better demonstrated by the fact
that, when exposed to the same atmosphere, bread becomes hard while
crackers become soft.
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Wolfgang Denk @ 2006-02-11 13:03 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ED7E1E.2030700@ovro.caltech.edu>
In message <43ED7E1E.2030700@ovro.caltech.edu> you wrote:
>
> What MPC834x development kit are you using? What would you recommend?
We use (*) the TQM834x modules (with a STK83xx/85xx starter kit).
(*) "use" means that we ported U-Boot and Linux for it.
> - I'd like to get a board in a PCI or cPCI-form factor, since
> I could use it as a PCI agent/peripheral
Both PCI and cPSI are present on the STK83xx board.
> - I'd really like to get access to the external bus
> too.
Available on headers, too
Feel free to contact me for details.
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
To know how another being, another creature feels - that is impos-
sible. - Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: Sylvain Munaut @ 2006-02-11 15:28 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: John Rigby, linuxppc-embedded
In-Reply-To: <1139592010.14894.22.camel@localhost.localdomain>
Asier Llano Palacios wrote:
> We are working with MPC5200 cpu.
> We've been using it since early 2.6 kernel versions.
> We're currently quite stabilished with the version of the kernel Sylvain
> had before the Platform Device rework. But the problem is that we are
> experiencing that the FEC stops working after a long uptime.
Did you ever observe that behavior on a lite5200 ?
What is 'long uptime' and do you have sustained transfer during that
period ? (To try reproduice the problem).
Also, what are the 'symptoms' ? (anything in dmesg ?)
> So, do you think that the current git version is more stable than the
> one we are using? Do you think that there is anything that could stop us
> upgrading to the latest version?
Doubtfull, I haven't touched the FEC code much except to remove the
aligment code (newer bestcomm microcode doesn't require alignement of
the skb). It should be reworked to use the generic phy code and remove
some "bugs" (like the fact when we down the interface, we stop the task
but not deactivate the MAC IIRC, which cause warning in dmesg).
You can send me the driver/net/fec_mpc52xx and arch/ppc/syslib/bestcomm
you're using, I'll tell you if there was major changes.
> The problem is that we have a custom board, with some custom devices, so
> it is not so easy to upgrade. We need to know that a new version, is
> more stable than the previous one, before we upgrade. As soon as we
> upgrade, we can help if we find any problem.
Sylvain
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: Wolfgang Denk @ 2006-02-11 16:08 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Asier Llano Palacios, John Rigby, linuxppc-embedded
In-Reply-To: <43EE029A.5040504@246tNt.com>
In message <43EE029A.5040504@246tNt.com> you wrote:
>
> > had before the Platform Device rework. But the problem is that we are
> > experiencing that the FEC stops working after a long uptime.
>
> Did you ever observe that behavior on a lite5200 ?
> What is 'long uptime' and do you have sustained transfer during that
> period ? (To try reproduice the problem).
This is a well-known problem, I'm afraid. To trigger it, it is
usually (*) sufficient to transfer a large file (700 MB or so) over
FTP to the target. Note that I've encountered the problem in the
context of the 2.4 kernel.
(*) In some cases you can run several such transfers in a row without
problem. Power-cycling the board will bring it back to "normal" mode.
It's probably Bestcomm related. See the previous discussions with
Freescale about known issues with the 2.6 Bestcomm code.
> Also, what are the 'symptoms' ? (anything in dmesg ?)
No, nothing.
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
Like winter snow on summer lawn, time past is time gone.
^ permalink raw reply
* [PPC,SOUND] Fix audio gpio state detection
From: Andreas Schwab @ 2006-02-11 16:10 UTC (permalink / raw)
To: alsa-devel; +Cc: linuxppc-dev
When booting with line out or headphone plugged, you won't hear anything.
The problem is that after reset all channels are muted, but the actual
value of the gpio port doesn't exactly match the active_val settings as
expected by check_audio_gpio. For example, the line_mute port is set to
7, but check_audio_gpio would expect 0xd or 0xf, thus its return value
indicates that it is not active, even though it is. AFAICS only looking
at the low bit is enough to determine whether the port is active.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Index: linux-2.6.16-rc2/sound/ppc/tumbler.c
===================================================================
--- linux-2.6.16-rc2.orig/sound/ppc/tumbler.c 2006-02-03 19:43:50.000000000 +0100
+++ linux-2.6.16-rc2/sound/ppc/tumbler.c 2006-02-11 03:46:30.000000000 +0100
@@ -207,7 +207,7 @@ static int check_audio_gpio(struct pmac_
ret = do_gpio_read(gp);
- return (ret & 0xd) == (gp->active_val & 0xd);
+ return (ret & 0x1) == (gp->active_val & 0x1);
}
static int read_audio_gpio(struct pmac_gpio *gp)
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* MBX AMD AM29F080 flash not recognized
From: dibacco @ 2006-02-11 16:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
on my MBX board I have two flashes: AM29F040 called bootrom and four chip=
s of AM29F080 (each one 8 Mbit for a total of 4MB).
The kernel (from DENX) doesn't find the AM29F080. I added the following i=
n amd_flash.c to support AM29F040 (a friend of mine told me)
#define AM29F040 0x00A4
and also:
{
mfr_id: MANUFACTURER_AMD,
dev_id: AM29F040,
name: "AMD AMD29F040",
size: 0x00080000,
numeraseregions: 1,
regions: {
{ offset: 0x000000, erasesize: 0x10000, numblocks: 8 },
}
},
in the amd_flash_info table.
For AM29F080 I don't know what to add and if to add something is ok !?!?!=
?!?
Someone knows?
Furthermore, how can I specify that there are 4 chips of AM29F080?
The kernel will handle this automatically?
Bye,
Antonio.
^ permalink raw reply
* [PATCH] remove duplicate exports
From: Olaf Hering @ 2006-02-11 17:21 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
A few symbols are exported twice, remove them from ppc_ksyms.c
Remove users of sys_ctrler in arch/ppc/
WARNING: vmlinux: duplicate symbol '__delay' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__up' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__down' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__down_interruptible' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'sys_ctrler' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strncat' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strncmp' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strchr' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strrchr' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strnlen' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strpbrk' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'memscan' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strstr' previous definition was in vmlinux
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/ppc_ksyms.c | 16 ----------------
arch/ppc/kernel/ppc_ksyms.c | 8 --------
arch/ppc/xmon/start.c | 15 +--------------
include/asm-ppc/machdep.h | 13 -------------
4 files changed, 1 insertion(+), 51 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/ppc_ksyms.c
@@ -78,15 +78,8 @@ EXPORT_SYMBOL(sys_sigreturn);
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
-EXPORT_SYMBOL(strncat);
-EXPORT_SYMBOL(strchr);
-EXPORT_SYMBOL(strrchr);
-EXPORT_SYMBOL(strpbrk);
-EXPORT_SYMBOL(strstr);
EXPORT_SYMBOL(strlen);
-EXPORT_SYMBOL(strnlen);
EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(strncmp);
EXPORT_SYMBOL(strcasecmp);
EXPORT_SYMBOL(csum_partial);
@@ -184,9 +177,6 @@ EXPORT_SYMBOL(adb_try_handler_change);
EXPORT_SYMBOL(cuda_request);
EXPORT_SYMBOL(cuda_poll);
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_PPC_PMAC
-EXPORT_SYMBOL(sys_ctrler);
-#endif
#ifdef CONFIG_VT
EXPORT_SYMBOL(kd_mksound);
#endif
@@ -204,7 +194,6 @@ EXPORT_SYMBOL(__lshrdi3);
EXPORT_SYMBOL(memcpy);
EXPORT_SYMBOL(memset);
EXPORT_SYMBOL(memmove);
-EXPORT_SYMBOL(memscan);
EXPORT_SYMBOL(memcmp);
EXPORT_SYMBOL(memchr);
@@ -213,7 +202,6 @@ EXPORT_SYMBOL(screen_info);
#endif
#ifdef CONFIG_PPC32
-EXPORT_SYMBOL(__delay);
EXPORT_SYMBOL(timer_interrupt);
EXPORT_SYMBOL(irq_desc);
EXPORT_SYMBOL(tb_ticks_per_jiffy);
@@ -221,10 +209,6 @@ EXPORT_SYMBOL(console_drivers);
EXPORT_SYMBOL(cacheable_memcpy);
#endif
-EXPORT_SYMBOL(__up);
-EXPORT_SYMBOL(__down);
-EXPORT_SYMBOL(__down_interruptible);
-
#ifdef CONFIG_8xx
EXPORT_SYMBOL(cpm_install_handler);
EXPORT_SYMBOL(cpm_free_handler);
Index: linux-2.6.16-rc2-olh/arch/ppc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/ppc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc2-olh/arch/ppc/kernel/ppc_ksyms.c
@@ -93,15 +93,8 @@ EXPORT_SYMBOL(test_and_change_bit);
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
-EXPORT_SYMBOL(strncat);
-EXPORT_SYMBOL(strchr);
-EXPORT_SYMBOL(strrchr);
-EXPORT_SYMBOL(strpbrk);
-EXPORT_SYMBOL(strstr);
EXPORT_SYMBOL(strlen);
-EXPORT_SYMBOL(strnlen);
EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(strncmp);
EXPORT_SYMBOL(strcasecmp);
EXPORT_SYMBOL(__div64_32);
@@ -253,7 +246,6 @@ EXPORT_SYMBOL(memcpy);
EXPORT_SYMBOL(cacheable_memcpy);
EXPORT_SYMBOL(memset);
EXPORT_SYMBOL(memmove);
-EXPORT_SYMBOL(memscan);
EXPORT_SYMBOL(memcmp);
EXPORT_SYMBOL(memchr);
Index: linux-2.6.16-rc2-olh/include/asm-ppc/machdep.h
===================================================================
--- linux-2.6.16-rc2-olh.orig/include/asm-ppc/machdep.h
+++ linux-2.6.16-rc2-olh/include/asm-ppc/machdep.h
@@ -154,19 +154,6 @@ extern char cmd_line[COMMAND_LINE_SIZE];
extern void setup_pci_ptrs(void);
-/*
- * Power macintoshes have either a CUDA or a PMU controlling
- * system reset, power, NVRAM, RTC.
- */
-typedef enum sys_ctrler_kind {
- SYS_CTRLER_UNKNOWN = 0,
- SYS_CTRLER_CUDA = 1,
- SYS_CTRLER_PMU = 2,
- SYS_CTRLER_SMU = 3,
-} sys_ctrler_t;
-
-extern sys_ctrler_t sys_ctrler;
-
#ifdef CONFIG_SMP
struct smp_ops_t {
void (*message_pass)(int target, int msg);
Index: linux-2.6.16-rc2-olh/arch/ppc/xmon/start.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/ppc/xmon/start.c
+++ linux-2.6.16-rc2-olh/arch/ppc/xmon/start.c
@@ -146,19 +146,6 @@ xmon_map_scc(void)
static int scc_initialized = 0;
void xmon_init_scc(void);
-extern void cuda_poll(void);
-
-static inline void do_poll_adb(void)
-{
-#ifdef CONFIG_ADB_PMU
- if (sys_ctrler == SYS_CTRLER_PMU)
- pmu_poll_adb();
-#endif /* CONFIG_ADB_PMU */
-#ifdef CONFIG_ADB_CUDA
- if (sys_ctrler == SYS_CTRLER_CUDA)
- cuda_poll();
-#endif /* CONFIG_ADB_CUDA */
-}
int
xmon_write(void *handle, void *ptr, int nb)
@@ -189,7 +176,7 @@ xmon_write(void *handle, void *ptr, int
ct = 0;
for (i = 0; i < nb; ++i) {
while ((*sccc & TXRDY) == 0)
- do_poll_adb();
+ ;
c = p[i];
if (c == '\n' && !ct) {
c = '\r';
--
short story of a lazy sysadmin:
alias appserv=wotan
^ 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