* 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
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 18:06 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110906.05547.sr@denx.de>
>>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.
Hi Stefan,
Nope, I can always work with the 440EP. I was just disappointed
to find that the 440EP had no way for an external host to
generate an interrupt (without coming up with the work-arounds
I suggested). I don't have the part designed into a board, I'm
merely evaluating it. So, I wanted to see what else was out
there with a similar set of features; the MPC834x has them.
So, now I have two possible processors to evaluate :)
I'll finish the other tests I want to do with the 440EP, get
myself a MPC834x and repeat the same tests with it (which
shouldn't take too long, since it'll be a repeat of the
440 tests).
The MPC834x does have features to make communications between a
host and a target (PCI 'agent') work much nicer than the 440EP.
It also appears to have a faster local bus. I haven't had time
to benchmark, or estimate from timing diagrams, the performance
of the 440EP external memory bus, but there is a chance that
it will fail to meet my spec.
I wouldn't consider the 440EP work to be wasted. Its been a good
learning experience, and mainly I've just been working on this
stuff in the evenings and weekends to see whether the processor
will work. This was my first experience with PowerPC processors,
so its all good fun!
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 18:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110921.33245.sr@denx.de>
> 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...
I always figure that if you can find it on a distributor web
site without having to explicitly ask for the part, then
it really is available. I got my Yosemite kit through
Avnet, so lets start there:
1. Avnet
http://www.em.avnet.com
Search for 440EP from the vendor AMCC, and it only shows up
the eval boards.
Search for 'contains' MPC834 from Freescale, and there are
lots of hits (though no stock for most of them).
2. Arrow North America
http://www.arrownac.com
No AMCC stuff there.
A search for the Freescale part shows up a bunch, although they
have no stock either.
The successful search hits for the Freescale part gives me
more confidence in those parts. However, you are correct, if I
really want to know the availablity of parts, I should talk
directly to an AMCC rep.
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 19:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110906.05547.sr@denx.de>
> 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.
Actually, its not the I2O unit I want, really just the doorbell
registers in the messaging unit. The MPC834x's seem to have
dropped the I2O units in that the 8272-family appears to
have, but they have the messaging unit registers.
I plan to create something like the ring-buffers scheme you
mention. And of course, you don't need an I2O unit to
implement it. However, you do need to be able to interrupt
the 440 from the host - which was the original issue.
But, there is a work-around :)
BTW, even with this scheme you really want to use DMA on
the adapter board for transfers in either direction, i.e.,
use the peripheral for both DMA read and write.
Unless of course you want to turn your 1GHz x86 host processor
into a 1MHz CPU. Check out the following performance tests
that I did between the current boards and an x86 host:
http://www.ovro.caltech.edu/~dwh/correlator/pdf/pci_performance.pdf
The boards use a PLX-9054 bridge and can DMA between themselves
at 118MB/s. However, the DMA through bridges, and DMA to/from host
bandwidth is less due to burst capabilites (or lack thereof) of
the bridges. CPU reads/writes by the host were dismal; look
at p19-26.
Of course, if I had used a PowerPC host I'm sure I would
have been fine!
Dave
^ permalink raw reply
* CONFIG_DEBUG_SLAB and non-cache coherent CPUs
From: Eugene Surovegin @ 2006-02-12 0:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I just wanted to let people on this list know that turning slab
debugging may cause slab corruption on non-coherent cache CPUs (4xx,
8xx).
The reason for this is that usually drivers which use DMA assume
L1 cache line alignment for buffers (e.g. returned from alloc_skb).
Unfortunately, with slab debugging enabled this is no longer the case,
and during cache invalidates we corrupt slab cache (or at least slab
poison markers).
I tried to define ARCH_KMALLOC_MINALIGN and/or ARCH_SLAB_MINALIGN but
it didn't work (and even if it did, it'd effectively disabled slab
debugging anyway).
I don't understand why slab debugging feature has to change allocation
alignment, as it can be obviously implemented without breaking this
alignment. Probably the reason is the usual one - nobody cares/cared
about non-coherent cache CPUs and saving couple of bytes was more
important :).
Anyway, I made a hack for my EMAC driver:
http://kernel.ebshome.net/emac_slab_debug.diff
which helps with this problem, although other drivers may experience
the same problem when used on 4xx/8xx with slab debugging enabled. In
fact, 3COM 905 driver crashed Ocotea in this configuration too.
--
Eugene
^ permalink raw reply
* system tick in PPC
From: dibacco @ 2006-02-12 17:47 UTC (permalink / raw)
To: linuxppc-embedded
Someone knows how the jiffies is incremented in PPC?
Using PIT, Decrementer or what?
Thanks,
Antonio.
^ permalink raw reply
* Re: system tick in PPC
From: Eugene Surovegin @ 2006-02-12 18:33 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUL5ER$96FFE4CFF38D6FFE5A07D5798F74338C@libero.it>
On Sun, Feb 12, 2006 at 06:47:15PM +0100, dibacco@inwind.it wrote:
> Someone knows how the jiffies is incremented in PPC?
> Using PIT, Decrementer or what?
I think you should be looking at include/asm-powerpc/time.h,
set_dec() & get_dec() functions.
timer_interrupt() uses set_dec().
In short, usually PPC uses decrementer, but some sub-archs are special.
--
Eugene
^ permalink raw reply
* Re:MBX AMD AM29F080 flash not recognized
From: dibacco @ 2006-02-12 20:17 UTC (permalink / raw)
To: dibacco; +Cc: linuxppc-embedded
Sorry, the problem was that I didn't configure the Interleave 4, and the =
MBX use 4 chips of AM29F080.
---------- Initial Header -----------
>From : linuxppc-embedded-bounces@ozlabs.org
To : "linuxppc-embedded" linuxppc-embedded@ozlabs.org
Cc :
Date : Sat, 11 Feb 2006 17:51:08 +0100
Subject : MBX AMD AM29F080 flash not recognized
> Hi,
>
> on my MBX board I have two flashes: AM29F040 called bootrom and four ch=
ips of AM29F080 (each one 8 Mbit for a total of 4MB).
>
> The kernel (from DENX) doesn't find the AM29F080. I added the following=
in 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.
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* PReP PCI resource allocations
From: Bob Brose @ 2006-02-12 21:01 UTC (permalink / raw)
To: linuxppc-dev
This is a 7248-133 43p. I had a lot of trouble with the early 2.6
kernels on this prep machine however 2.6.14.7 runs well (the
vga console driver even works now). There is one thing I noticed
different from 2.4.32 involving PCI resources. On 2.6.14.7 I get...
Total memory = 192MB; using 512kB for hash table (at c0300000)
Linux version 2.6.14.7 (root@oldbb) (gcc version 4.0.3 20051201 (prerelease)
(Debian 4.0.2-5)) #4 Fri Feb 10 13:27:45 CST 2006
PReP architecture
IBM planar ID: f7
...
PCI: Probing PCI hardware
Setting PCI interrupts for a "IBM 7248, PowerSeries 830/850 (Carolina)"
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0
PCI: Cannot allocate resource region 1 of device 0000:00:0c.0
PCI: Cannot allocate resource region 0 of device 0000:00:10.0
The regions correspond to:
Region 0: I/O ports at 80001020 [size=32] of the builtin pcnet32 ethernet.
Region 1: Memory at c0800100 (32-bit, non-prefetchable) [size=32] pcnet32..
Region 0: I/O ports at 80001400 [size=256] of the Symbios Logic 53c810 scsi.
Both the ethernet and scsi work fine though..
2.4.32 remaps these...
Linux version 2.4.32 (root@oldbb) (gcc version 2.95.4 20011002
(Debian prerelease)) #2 Tue Feb 7 12:30:21 CST 2006
PReP architecture
IBM planar ID: 000000f7
...
PCI: Cannot allocate resource region 0 of device 00:0c.0
PCI: Cannot allocate resource region 0 of device 00:10.0
PCI: moved device 00:0c.0 resource 0 (101) to 1020
PCI: moved device 00:0c.0 resource 1 (200) to 0
PCI: moved device 00:10.0 resource 0 (101) to 1400
Is this important??
2.6.15 BTW doesn't work at all. I need to hook up a serial console to
see if I can figure out what is going on...
Bob
^ permalink raw reply
* SPI Katix subsytem
From: dibacco @ 2006-02-12 21:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I would like to use a SPI subsystem on 2.4 but katix framework seems to b=
e not continuosly updated. Katix is also present in 2.6 or is there anot=
her more supported framework there?
Bye,
Antonio.
^ 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