* Some problem about code reading
From: enorm @ 2006-08-30 13:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi,
I met some problems when reading sourcecode of u-boot 1.1.4 (for mpc85xx)
file /cpu/mpc85xx/start.s line 276
276. #if (CFG_CCSRBAR_DEFAULT != CFG_CCSRBAR)
277. /* Special sequence needed to update CCSRBAR itself */
278. lis r4, CFG_CCSRBAR_DEFAULT@h
279. ori r4, r4, CFG_CCSRBAR_DEFAULT@l
280.
281. lis r5, CFG_CCSRBAR@h
282. ori r5, r5, CFG_CCSRBAR@l
283. srwi r6,r5,12
284. stw r6, 0(r4)
285. isync
286.
287. lis r5, 0xffff
288. ori r5,r5,0xf000
289. lwz r5, 0(r5)
290. isync
291.
292. lis r3, CFG_CCSRBAR@h
293. lwz r5, CFG_CCSRBAR@l(r3)
294. isync
295. #endif
I think it means if we don't use default CCSRBAR, we put the CCSRBAR addr actually used to the proper place in default CCSRBAR, so that it can jump to the addr we want to automatically.(line 276-286).
But, I don't know what line 287-294 does. Can some one tell me pls?
Thanks for your help.
[-- Attachment #2: Type: text/html, Size: 2538 bytes --]
^ permalink raw reply
* could not access the address in linux-System ace driver
From: sudheer @ 2006-08-30 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: raja_chidambaram82
In-Reply-To: <44EB1DC2.5070307@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12198 bytes --]
Hello All
I'm really desperate for some help , I've been struggling with this
system since few days.
sudheer wrote:
> Hello Raja,
>
> We too are working on customized board with amcc 440SPe processor ,
> xilinx System Ace controller. Compact flash is connected to system
> ace controller.
> We use u-boot 1.1.2 as bootloader & linux kernel - 2.6.16-2.
>
> System ace is connected to amcc440SPE processor via GPIO and External
> Peripheral Bus Controller(EBC).
I am still facing the issue in accessing the address in linux.
The physical address given in u-boot init.S tlbentry for 'system ace'
is 0xE0000000
I am able to access the address in u-boot and everything is fine in u-boot.
But in linux , I am able to ioremap the the address 0xE0000000 but the
kernel crashes when i try to access the address .
physical address=0xe0000000
address_after_ioremap = 0xe1000000.
I am trying to read with readw(address_after_ioremap)
The kernel gives an exception error saying Oops: machine check, sig: 7
[#2] .
The error dump is as below:
Instruction dump:
Data machine check in kernel mode.
PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR= 0x0000000000008000
PLB1: BEAR=0xe98d7ad33716ee7e ACR= 0xdb000000 BESR= 0x0000000000000000
POB0: BEAR=0x0000000fffaebbcd BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C0002200 CTR: 00000000
REGS: c0241f50 TRAP: 0202 Not tainted (2.6.16.2)
MSR: 00000000 <> CR: 84CA4124 XER: 00000000
TASK = dff6cb70[1] 'swapper' THREAD: c0740000
GPR00: 00000000 C0241E40 DFF6CB70 00000001 FFFFFFD0 00000000 C0240000
C01F3C0C
GPR08: C01F0000 C0002200 00021002 C0001FF4 DFF6CD38 802823E0 1FFB9600
00000000
GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3540 1FF63CE0 1FFCEE78
C01C0000
GPR24: C01C0000 C01C0000 C01F0000 C01C0000 BFFFFFFF FFFFFFD0 00000000
C0241F50
NIP [00000000] 0x0
LR [C0002200] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
Data machine check in kernel mode.
PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR= 0x0000000000008000
.........and this dump gets print continously.
I have checked with TLB entries in u-boot and linux using BDI:
BDI_AMCC440SPe>tlb 0 10
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 00 ff000000 16MB V0 -> 4_ff000000 U:0000 WI-G- XWRXWR
1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
2 : 00 10000000 256MB V0 -> 0_10000000 U:0000 -I-G- XWRXWR
3 : 00 20000000 256MB V0 -> 0_20000000 U:0000 -I-G- XWRXWR
4 : 00 30000000 256MB V0 -> 0_30000000 U:0000 -I-G- XWRXWR
5 : 00 90000000 256KB V0 -> 4_00000000 U:0000 -I--- XWRXWR
6 : 00 e0000000 1KB V0 -> 4_e0000000 U:0000 -I-G- -WR-WR
7 : 00 a0000000 4KB V0 -> 4_f0000000 U:0000 -I-G- -WR-WR
8 : 00 d0000000 256MB V0 -> c_00000000 U:0000 -I-G- -WR-WR
9 : 00 80000000 256MB V0 -> c_10000000 U:0000 -I-G- -WR-WR
10 : 00 01080000 1KB -0 -> 0_00000000 U:0000 ----- ------
BDI_AMCC440SPe>
In Linux the tlb entries are as below.......
BDI_AMCC440SPe>tlb 0 63
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 0e 0ff1a000 4KB V0 -> 0_007ce000 U:0000 --MG- --R--R
1 : 0e 0fe94000 4KB V0 -> 0_1ff96000 U:0000 ---G- X-RX-R
2 : 0e 30017000 4KB V0 -> 0_007cd000 U:0000 --MG- --R-WR
3 : 0e 10039000 4KB V0 -> 0_1ffb8000 U:0000 ---G- X-RX-R
4 : 0e 30009000 4KB V0 -> 0_00758000 U:0000 ---G- X-RX-R
5 : 0e 30010000 4KB V0 -> 0_0078b000 U:0000 ---G- X-RX-R
6 : 0e 00000000 1KB -0 -> 0_1f4e2000 U:0000 ---G- --R--R
7 : 0e 0fe3e000 4KB V0 -> 0_1f4e2000 U:0000 ---G- X-RX-R
8 : 0e 0ff1c000 4KB V0 -> 0_007ed000 U:0000 --MG- XWRXWR
9 : 0e 0ff1e000 4KB V0 -> 0_007ee000 U:0000 --MG- -WR-WR
10 : 0e 0ff1f000 4KB V0 -> 0_007ea000 U:0000 --MG- XWRXWR
11 : 0e 0fe39000 4KB V0 -> 0_1ff8e000 U:0000 ---G- X-RX-R
12 : 0e 0ff21000 4KB V0 -> 0_007a8000 U:0000 --MG- --R-WR
13 : 0e 0fe47000 4KB V0 -> 0_1ffa9000 U:0000 ---G- X-RX-R
14 : 0e 0fe46000 4KB V0 -> 0_1ffb2000 U:0000 ---G- X-RX-R
15 : 0e 30019000 4KB V0 -> 0_007c5000 U:0000 --MG- -WR-WR
16 : 0e 0fe45000 4KB V0 -> 0_1ffa8000 U:0000 ---G- X-RX-R
17 : 00 fdfff000 4KB V0 -> 4_f0000000 U:0000 -IMG- ----WR
18 : 0e 0fe9a000 4KB V0 -> 0_1ff98000 U:0000 ---G- X-RX-R
19 : 0e 10067000 4KB V0 -> 0_0078e000 U:0000 --MG- -WR-WR
20 : 0e 00000000 4KB -0 -> 0_1f4e5000 U:0000 ---G- --R--R
21 : 0e 10030000 4KB V0 -> 0_1f4e5000 U:0000 ---G- X-RX-R
22 : 0e 10063000 4KB V0 -> 0_007b7000 U:0000 --MG- -WR-WR
23 : 0e 0fe4c000 4KB V0 -> 0_1ff9b000 U:0000 ---G- X-RX-R
24 : 0e 1007f000 4KB V0 -> 0_007e0000 U:0000 --MG- -WR-WR
25 : 0e 0ff1d000 4KB V0 -> 0_007c6000 U:0000 --MG- --R-WR
26 : 0e 0fe4e000 4KB V0 -> 0_1ffa1000 U:0000 ---G- X-RX-R
27 : 0e 0fe0f000 4KB V0 -> 0_0077e000 U:0000 ---G- X-RX-R
28 : 0e 0fe52000 4KB V0 -> 0_0077f000 U:0000 ---G- X-RX-R
29 : 0e 0fe53000 4KB V0 -> 0_1ff80000 U:0000 ---G- X-RX-R
30 : 0e 0fef9000 4KB V0 -> 0_1ff81000 U:0000 ---G- --R--R
31 : 0e 0fe3b000 4KB V0 -> 0_1ffa7000 U:0000 ---G- X-RX-R
32 : 0e 7f901000 4KB V0 -> 0_007db000 U:0000 --MG- -WR-WR
33 : 0e 10027000 4KB V0 -> 0_1ffd0000 U:0000 ---G- X-RX-R
34 : 0e 1003a000 4KB V0 -> 0_1ffb6000 U:0000 ---G- X-RX-R
35 : 0e 0fe51000 4KB V0 -> 0_00775000 U:0000 ---G- X-RX-R
36 : 0e 1003b000 4KB V0 -> 0_1ffb7000 U:0000 ---G- X-RX-R
37 : 0e 1002a000 4KB V0 -> 0_1ffcf000 U:0000 ---G- X-RX-R
38 : 0e 10066000 4KB V0 -> 0_007de000 U:0000 --MG- -WR-WR
39 : 0e 1002b000 4KB V0 -> 0_1ffd3000 U:0000 ---G- X-RX-R
40 : 0e 1002c000 4KB V0 -> 0_1ffd2000 U:0000 ---G- X-RX-R
41 : 0e 1005d000 4KB V0 -> 0_007f4000 U:0000 --MG- XWRXWR
42 : 0e 1002d000 4KB V0 -> 0_1ffc2000 U:0000 ---G- X-RX-R
43 : 0e 10028000 4KB V0 -> 0_1ffc8000 U:0000 ---G- X-RX-R
44 : 0e 10069000 4KB V0 -> 0_0078d000 U:0000 --MG- -WR-WR
45 : 0e 1002e000 4KB V0 -> 0_1ffd4000 U:0000 ---G- X-RX-R
46 : 0e 1005e000 4KB V0 -> 0_007a7000 U:0000 --MG- X-RXWR
47 : 0e 0fe11000 4KB V0 -> 0_0077a000 U:0000 ---G- X-RX-R
48 : 0e 10047000 4KB V0 -> 0_1ffcd000 U:0000 ---G- --R--R
49 : 0e 1007e000 4KB V0 -> 0_007d0000 U:0000 --MG- --R-WR
50 : 0e 0fea1000 4KB V0 -> 0_1ffd5000 U:0000 ---G- X-RX-R
51 : 0e 10026000 4KB V0 -> 0_1ffc9000 U:0000 ---G- X-RX-R
52 : 0e 0fe0e000 4KB V0 -> 0_1ffd1000 U:0000 ---G- X-RX-R
53 : 0e 0fe96000 4KB V0 -> 0_1ffce000 U:0000 ---G- X-RX-R
54 : 0e 1002f000 4KB V0 -> 0_1f4c1000 U:0000 ---G- X-RX-R
55 : 0e 7f900000 4KB V0 -> 0_0078f000 U:0000 --MG- -WR-WR
56 : 0e 10036000 4KB V0 -> 0_1f4c0000 U:0000 ---G- X-RX-R
57 : 0e 1004b000 4KB V0 -> 0_1ffcc000 U:0000 ---G- --R--R
58 : 0e 0fe9b000 4KB V0 -> 0_1ff88000 U:0000 ---G- X-RX-R
59 : 0e 0fe4d000 4KB V0 -> 0_1ffa0000 U:0000 ---G- X-RX-R
60 : 0e 10080000 4KB V0 -> 0_00793000 U:0000 --MG- -WR-WR
61 : 0e 0fe95000 4KB V0 -> 0_1ff99000 U:0000 ---G- X-RX-R
62 : 00 d0000000 256MB V0 -> 0_10000000 U:0000 ---G- ---XWR
63 : 00 c0000000 256MB V0 -> 0_00000000 U:0000 ---G- ---XWR
BDI_AMCC440SPe>
I could not see the tlb entry for system ace in the linux level, But in
the kernel error message, the physical address address can be seen
EBC's BEAR=0x00000000e0000000 saying the ioremap is done properly and
phys-addr is obtaining from virtual adr given.
I could not understand what is going wrong. When i try to read/write
using the ioremapped address, the kernel crashes. Even from the
Error/Status reg(EBC's BESR in the error dump) could not get any
information.
Can someone please be so kind to help me debug this...what might be
wrong / what should I do to try and get a better understanding of what
is going wrong?
please let me if any details required.
Thank you in advance
Regards
Sudheer
>
> While booting the linux, it crashes when i am trying to
> access(read/write) a system ace register.
> In the u-boot though i have support, as of now i am not doing
> anything with system ace as it not required now.
> In u-boot/include/configs/custom_board.h, i could see
> #define CFG_ACE_BASE 0xe0000000 /* Xilinx ACE
> controller - Compact Flash */
> So i have used this address in Linux driver to to ioremap to access
> the ace registers. Though i could do ioremap, it crashes while
> booting exactly when it is trying the access any ace register.
>
> I doubt with the address i have used . But could not get any clue from
> the docs given.
>
> I want to know how to access the system ace registers and how to get
> the address to ioremap. Please let me know if any details required and
> also if i am missing any fundamentals.
>
>
> Thanks & Regards
> Sudheer
>
>
>
>
> sudheer wrote:
>> Hi Ameet,
>>
>> Firstly, thanks for the mail.
>>
>> I am able to compile the linux-2.6.16 and got the ace support files with
>> the patch.
>> While compiling got some errors with xparameters, but am rectify them.
>>
>> I need to wait for the hardware to test the source.
>>
>> Thanks & Regards
>> Sudheer
>>
>>
>> Ameet Patil wrote:
>>
>>> Hi Sudheer,
>>> Frank has already answered your questions. If you have any problems
>>> with the SysAce patch... do let me know. I have written a small
>>> tutorial here if it helps...
>>>
>>> http://linux.get2knowmore.com
>>>
>>>
>>> -Ameet
>>>
>>> sudheer wrote:
>>>
>>>> Hello Ameet Patil
>>>>
>>>> I am looking for linux kernel source 2.6.16 with system ace
>>>> controller support. I downloaded the linux-2.6.16 and linux-2.6.17-1
>>>> source from kernel.org but could not find any files related to system
>>>> ace controller ( No xilinx_sysace directory in drivers/block/) . I
>>>> have checked penguinppc.org also but could not get it.
>>>>
>>>> Can you please send to me the link where i could download the
>>>> linuxppc-2.6.16 source with system ace support.
>>>>
>>>> Thanks & Regards
>>>> Sudheer
>>>>
>>>> Ameet Patil wrote:
>>>>
>>>>> Hi Raja,
>>>>> I have ported the Xilinx System ACE driver to 2.6 kernel. Find
>>>>> the latest one here:
>>>>> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>>>>>
>>>>>
>>>>> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
>>>>> which case use the -after-TEMAC patch found in the patches folder
>>>>> above.
>>>>>
>>>>> Check the following discussions (threads) for more details:
>>>>> 1. "Xilinx SystemACE driver for 2.6"
>>>>> 2. "Xilinx BSP for linux 2.6"
>>>>> 3. "Kernel hangs after "Now booting the kernel"."
>>>>>
>>>>> cheers,
>>>>> -Ameet
>>>>>
>>>>> Raja Chidambaram wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>> We are working on customized board with amcc 440SPe
>>>>>> processor & xilinx System Ace controller. The System
>>>>>> Ace controller is connected to compact flash driver.
>>>>>>
>>>>>> We use u-boot 1.2 as bootloader & linux kernel
>>>>>> 2.6.16-2.
>>>>>>
>>>>>> On the process the u-boot is able to detect compact
>>>>>> flash through Xilinx SystemAce controller & able to
>>>>>> load the kernel image into compact flash.But when the
>>>>>> linux boot's up it not able to detect the System Ace
>>>>>> controller or compact flash.
>>>>>>
>>>>>> Note:we need to have the root file system in compact
>>>>>> flash.
>>>>>>
>>>>>> Is their any drivers available for SystemAce
>>>>>> controller on linux 2.6,if their how to get it.please
>>>>>> help me in this
>>>>>> with regards
>>>>>> raja
>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________
>>>>>> Do You Yahoo!?
>>>>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>>>>> http://mail.yahoo.com _______________________________________________
>>>>>> Linuxppc-embedded mailing list
>>>>>> Linuxppc-embedded@ozlabs.org
>>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 15380 bytes --]
^ permalink raw reply
* Re: DS1302 driver for powerpc
From: Matt Porter @ 2006-08-30 13:55 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5B@ASPROEXG.astri.local>
On Wed, Aug 30, 2006 at 07:54:16PM +0800, Chun Chung Lo wrote:
>
> Hi all,
>
> I am now doing a STB project and the development board uses a DS1302
> (trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP
> with a linux kernel 2.4.20 running on it. And the DS1302 is controlled
> by 2 GPIO pins instead of I2C.
>
> I would like to ask are there any porting of DS1302 support under ppc
> architecture? (I can only find DS1302 is supported under cris
> architecture.)
There doesn't seem to be any DS1302 support "for ppc" available. However,
even if there were a platform with DS1302 support you'd be in the same
boat as the low-level support for cris. Support for DS1302 has a glue
layer that's board-specific based on what GPIO pins are used to drive
it. So if you had this driver for another PPC system like 83xx you'd
still have no better starting point than the cris ds1302 driver glue
since the GPIO mechanism/connection is different. Porting the
board-specific glue from arch/cris/drivers/ds1302.c to 4xx GPIO is
trivial to do though.
-Matt
^ permalink raw reply
* Re: How to turn off MMU in MPC8540
From: Kumar Gala @ 2006-08-30 13:31 UTC (permalink / raw)
To: Reddy Suneel-ASR125; +Cc: linuxppc-embedded
In-Reply-To: <405ECA8A30557F439A723E52D50838F9D8295F@ZMY16EXM66.ds.mot.com>
On Aug 30, 2006, at 1:25 AM, Reddy Suneel-ASR125 wrote:
> Hi
>
> Can anyone know how to turn off MMU in MPC8540?
You can not turn the MMU off on the MPC8540 or any e500 based
product. You can emulate a 1:1 mapping if you so desire by
preloading TLBs.
- kumar
^ permalink raw reply
* Re: [PATCH] corrected PCI interrupt sense values to level low inmpc8349emds.dts
From: Kumar Gala @ 2006-08-30 13:29 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev, Phillips Kim-R1AAHA
In-Reply-To: <995B09A8299C2C44B59866F6391D263511BA03@zch01exm21.fsl.freescale.net>
> Where these IDSEL 0x15~0x18 come from on 8349EMDS board?
> Please expain it.
This is from the docs on the PMC-PCI expansion boards that state what
IDSELs are used and how they are wired up.
- k
^ permalink raw reply
* RE: 2 Ethernet port operating in a PPC405EP system
From: Chun Chung Lo @ 2006-08-30 13:17 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hi,
I know my source code is vert old. But since there are lots of
applications developed base on this 2 sets of source code, if the kernel
and U-Boot needs to change, the above applications (tons of codes) also
need to revise ... (lots of multimedia players, drivers, and other
supporting tools). My team cannot afford such great change.
So I say "update is not recommended" ...=0D
Thanks for your quick reply.
Best regards,
Lo Chun Chung
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Wednesday, 30 August, 2006 9:07 PM
To: Chun Chung Lo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 2 Ethernet port operating in a PPC405EP system=0D
In message
<A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local> you
wrote:
>=0D
> Sorry for such long e-mail.
Actually it's not so long...
> I am now working on a STB project, and our board is a IBM PPC405EP=0D
> with 2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista)
> is used and update is not recommended. Each ethernet port has a=0D
> RTL8021CP PHY connected.
... as reading stops here. Both U-Boot 1.0.0 and Linux 2.4.20 are not
only old, they are ancient. Zillions of smaller and bigger bugs have
been fixed since. Do yourself a favour and use current code.
Best regards,
Wolfgang Denk
--=0D
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Hirokazu Takata @ 2006-08-30 13:03 UTC (permalink / raw)
To: linux-ia64, linux-mips, linuxppc-embedded, paulkf, takata,
linux-kernel
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
From: Russell King <rmk+lkml@arm.linux.org.uk>
Subject: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
Date: Mon, 28 Aug 2006 09:52:44 +0100
> diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
> --- a/drivers/serial/m32r_sio.c
> +++ b/drivers/serial/m32r_sio.c
> @@ -76,17 +76,16 @@
> */
> #define is_real_interrupt(irq) ((irq) != 0)
>
> -#include <asm/serial.h>
> +#define BASE_BAUD 115200
>
> /* Standard COM flags */
> #define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
>
> /*
> * SERIAL_PORT_DFNS tells us about built-in ports that have no
> * standard enumeration mechanism. Platforms that can find all
> * serial ports via mechanisms like ACPI or PCI need not supply it.
> */
> -#undef SERIAL_PORT_DFNS
> #if defined(CONFIG_PLAT_USRV)
>
> #define SERIAL_PORT_DFNS \
> @@ -109,7 +108,7 @@
> #endif /* !CONFIG_PLAT_USRV */
>
> static struct old_serial_port old_serial_port[] = {
> - SERIAL_PORT_DFNS /* defined in asm/serial.h */
> + SERIAL_PORT_DFNS
> };
>
> #define UART_NR ARRAY_SIZE(old_serial_port)
>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Thank you.
-- Takata
^ permalink raw reply
* Re: 2 Ethernet port operating in a PPC405EP system
From: Wolfgang Denk @ 2006-08-30 13:07 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local>
In message <A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local> you wrote:
>
> Sorry for such long e-mail.
Actually it's not so long...
> I am now working on a STB project, and our board is a IBM PPC405EP with
> 2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista) is
> used and update is not recommended. Each ethernet port has a RTL8021CP
> PHY connected.
... as reading stops here. Both U-Boot 1.0.0 and Linux 2.4.20 are not
only old, they are ancient. Zillions of smaller and bigger bugs have
been fixed since. Do yourself a favour and use current code.
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 software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* 2 Ethernet port operating in a PPC405EP system
From: Chun Chung Lo @ 2006-08-30 12:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Sorry for such long e-mail.
I am now working on a STB project, and our board is a IBM PPC405EP with
2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista) is
used and update is not recommended. Each ethernet port has a RTL8021CP
PHY connected.=0D
Under u-boot environment, only 1 ethernet port is operating. But
sometimes the port is not able to PING other PCs within the same subnet.
Also some modifications are made (under bd_t) to let linux kernel fetch
2 different MAC address when boot into linux kernel.
Error log (U-Boot):
<## snip ##>
Hit any key to stop autoboot: 0
=3D> setenv ipaddr 10.6.64.343
=3D> setenv ipaddr 10.6.64.34
=3D> ping 10.6.64.128
ENET Speed is 100 Mbps - FULL duplex connection
< the board holds here about several seconds >
ping failed; host 10.6.64.128 is not alive
<## snip ##>
Under linux environment, 2 ethernet ports are operating. But sometimes
only ethernet 1 is operating (by running a udhcpc, from
busybox-v1.00-pre8); sometimes both are not operating.=0D
When ethernet 1 is operating (can fetch a IP address from DHCP server,
say 10.6.64.111), then I assigned a static IP address (say,
192.168.1.120) and let the board PING to different subnets at the same
time. But the ethernet 2 cannot PING out while ethernet 1 is operating
...=0D
Error log (Linux):
<## snip ##>
Press CTRL-C to enter shell within 1 sec
~ # udhcpc -i eth0 -s /etc/udhcpc.sh
info, udhcpc (v0.9.9-pre) started
debug, Sending discover...
debug, Sending discover...
< the ethernet port 1 goes wrong and cannot get IP from DHCP server,
until I plug and unplug the ethernet cable several times, it works again
>
debug, Sending discover...
debug, Sending select for 10.6.64.197...
info, Lease of 10.6.64.197 obtained, lease time 691200
deleting routers
SIOCDELRT: No such process
adding dns 10.6.2.11
adding dns 10.6.2.12
~ # ping 10.6.64.128
PING 10.6.64.128 (10.6.64.128): 56 data bytes
64 bytes from 10.6.64.128: icmp_seq=3D0 ttl=3D64 time=3D9.4 ms
64 bytes from 10.6.64.128: icmp_seq=3D1 ttl=3D64 time=3D0.3 ms
64 bytes from 10.6.64.128: icmp_seq=3D2 ttl=3D64 time=3D0.3 ms
--- 10.6.64.128 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max =3D 0.3/3.3/9.4 ms
~ # ifconfig eth1 192.168.1.120
EMAC1 open, with PHY @ 0x13
ibm_ocp_phy.c: cclo - fep->link =3D 1
------ phy: RTL8201CP, mii_parse_anar(0x000001e1), phy=3D0x13 ------
eth1: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation
complete.
eth1: IBM EMAC: MAC cc:0b:20:08:21:b2.
~ # ping 192.168.1.123
PING 192.168.1.123 (192.168.1.123): 56 data bytes
--- 192.168.1.123 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #
<## snip ##>
I also serached something about this issue on internet, I found
something:
http://ozlabs.org/pipermail/linuxppc-embedded/2003-December/012802.html
Are there any updates about this issue? Or my problem is not related to
this?
Please help. Thanks.
Best regards,
Lo Chun Chung
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* DS1302 driver for powerpc
From: Chun Chung Lo @ 2006-08-30 11:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am now doing a STB project and the development board uses a DS1302
(trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP
with a linux kernel 2.4.20 running on it. And the DS1302 is controlled
by 2 GPIO pins instead of I2C.=0D
I would like to ask are there any porting of DS1302 support under ppc
architecture? (I can only find DS1302 is supported under cris
architecture.)
Thanks all.
Best regards,
Lo Chun Chung
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Herbert Xu @ 2006-08-30 11:09 UTC (permalink / raw)
To: Joy Latten, paulus, anton, linuxppc-dev; +Cc: jmorris, gcwilson, davem, netdev
In-Reply-To: <20060829013023.GA5865@gondor.apana.org.au>
Hi:
Thanks to some excellent info from Joy, I've trakced the problem down to
a broken implementation of memmove on ppc64, which in turn is due to a
broken memcpy.
Both memmove and memcpy need to return the destination pointer as per
the C standard. The ppc64 version of memcpy returns a pointer to the
last byte copied instead. Since memmove degenerates into memcpy in
some cases, this makes it broken as well.
Something like the following patch should fix the problem. Be warned
that I know absolutely nothing about ppc assembly so don't come back
to me if this patch eats your disk :)
BTW, I spotted a couple of typos in memcpy_64.S/copyuser_64.S where
"cmpldi cr1,..." became "cmpldi r1,...". So please fix that up while
you ppc64 guys are at it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index fd66acf..9e8d9e7 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S
@@ -11,6 +11,7 @@ #include <asm/ppc_asm.h>
.align 7
_GLOBAL(memcpy)
+ std r3,-8(r1)
mtcrf 0x01,r5
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
@@ -53,7 +54,8 @@ _GLOBAL(memcpy)
2: bf cr7*4+3,3f
rotldi r9,r9,8
stb r9,0(r3)
-3: blr
+3: ld r3,-8(r1)
+ blr
.Lsrc_unaligned:
srdi r6,r5,3
@@ -167,4 +169,5 @@ _GLOBAL(memcpy)
3: bf cr7*4+3,4f
lbz r0,0(r4)
stb r0,0(r3)
-4: blr
+4: ld r3,-8(r1)
+ blr
^ permalink raw reply related
* Re: Fwd: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Paul Mackerras @ 2006-08-30 10:02 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev, trini
In-Reply-To: <20060830092827.GB19689@flint.arm.linux.org.uk>
Russell King writes:
> Maybe this should've gone to linuxppc-dev? Can PPC folk please look
> at the PPC bits of this patch, and also decide whether the following
> can also have asm/serial.h removed:
>
> arch/ppc/4xx_io/serial_sicc.c
> arch/ppc/boot/simple/mpc52xx_tty.c
> arch/ppc/boot/simple/mv64x60_tty.c
The situation is that arch/ppc is the old world. Platforms are being
moved over to arch/powerpc as fast as we can manage, where things will
be much cleaner because the information about type and location of
serial ports (among other things) will be supplied via a device tree
rather than hardcoded in header files. This means, though, that there
isn't much motivation for cleaning up stuff in arch/ppc.
The two users in arch/ppc/boot aren't really part of the kernel
proper. The compressed image bootwrapper uses definitions from
serial.h on some platforms to access a serial port for interaction
with the user. It may be possible to replicate the string of #ifdefs
and #includes from serial.h in those files. Tom Rini can best advise
about that.
The serial_sicc.c code looks like it should be converted to use the
serial_core stuff. I hope that will get done in the process of moving
4xx over to arch/powerpc.
Paul.
^ permalink raw reply
* Fwd: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Russell King @ 2006-08-30 9:28 UTC (permalink / raw)
To: linuxppc-dev
Maybe this should've gone to linuxppc-dev? Can PPC folk please look
at the PPC bits of this patch, and also decide whether the following
can also have asm/serial.h removed:
arch/ppc/4xx_io/serial_sicc.c
arch/ppc/boot/simple/mpc52xx_tty.c
arch/ppc/boot/simple/mv64x60_tty.c
Thanks.
----- Forwarded message from Russell King <rmk+lkml@arm.linux.org.uk> -----
Date: Mon, 28 Aug 2006 09:52:44 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
linuxppc-embedded@ozlabs.org, paulkf@microgate.com,
takata@linux-m32r.org, linux-kernel@vger.kernel.org
Subject: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
asm/serial.h is supposed to contain the definitions for the architecture
specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
but this is the base baud for the architecture specific ports _only_.
Therefore, nothing other than the 8250 driver should be including this
header file. In order to move towards this goal, here is a patch which
removes some of the more obvious incorrect includes of the file.
MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
related to non-8250 ports. Hence, it's not trivial to conclude that
these includes are indeed unnecessary, so can mips and ppc people please
test this patch carefully.
Thanks.
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
--- a/arch/frv/kernel/setup.c
+++ b/arch/frv/kernel/setup.c
@@ -31,7 +31,6 @@
#include <linux/serial_reg.h>
#include <asm/setup.h>
-#include <asm/serial.h>
#include <asm/irq.h>
#include <asm/sections.h>
#include <asm/pgalloc.h>
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -54,7 +54,6 @@
#include <asm/processor.h>
#include <asm/sal.h>
#include <asm/sections.h>
-#include <asm/serial.h>
#include <asm/setup.h>
#include <asm/smp.h>
#include <asm/system.h>
diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
--- a/arch/mips/cobalt/setup.c
+++ b/arch/mips/cobalt/setup.c
@@ -23,7 +23,6 @@
#include <asm/processor.h>
#include <asm/reboot.h>
#include <asm/gt64120.h>
-#include <asm/serial.h>
#include <asm/mach-cobalt/cobalt.h>
diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
--- a/arch/mips/lasat/setup.c
+++ b/arch/mips/lasat/setup.c
@@ -34,7 +34,6 @@
#include <asm/cpu.h>
#include <asm/bootinfo.h>
#include <asm/irq.h>
-#include <asm/serial.h>
#include <asm/lasat/lasat.h>
#include <asm/lasat/serial.h>
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,7 +38,6 @@
#include <asm/nvram.h>
#include <asm/xmon.h>
#include <asm/time.h>
-#include <asm/serial.h>
#include <asm/udbg.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -57,7 +57,6 @@
#include <linux/netdevice.h>
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -87,7 +87,6 @@
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -76,17 +76,16 @@
*/
#define is_real_interrupt(irq) ((irq) != 0)
-#include <asm/serial.h>
+#define BASE_BAUD 115200
/* Standard COM flags */
#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
/*
* SERIAL_PORT_DFNS tells us about built-in ports that have no
* standard enumeration mechanism. Platforms that can find all
* serial ports via mechanisms like ACPI or PCI need not supply it.
*/
-#undef SERIAL_PORT_DFNS
#if defined(CONFIG_PLAT_USRV)
#define SERIAL_PORT_DFNS \
@@ -109,7 +108,7 @@
#endif /* !CONFIG_PLAT_USRV */
static struct old_serial_port old_serial_port[] = {
- SERIAL_PORT_DFNS /* defined in asm/serial.h */
+ SERIAL_PORT_DFNS
};
#define UART_NR ARRAY_SIZE(old_serial_port)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
--
Russell King
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Gerhard Pircher @ 2006-08-30 9:01 UTC (permalink / raw)
To: Marcus Comstedt; +Cc: linuxppc-dev
In-Reply-To: <yf9mz9np82b.fsf@omoikane.mc.pp.se>
-------- Original-Nachricht --------
Datum: Tue, 29 Aug 2006 23:04:44 +0200
Von: Marcus Comstedt <marcus@mc.pp.se>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
Betreff: Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
>
> "Gerhard Pircher" <gerhard_pircher@gmx.net> writes:
>
> > Hi Marcus,
> >
> > I guess this message should also be forwarded to
> > linux-usb-devel@lists.sourceforge.net. I hope the developers there can
> > make some comments.
> >
> > Gerhard
>
>
> Well, I figured the first thing to do would be to reach a consensus
> here on whether or not atomic_t:s in DMA memory should be ruled as
> unallowed. Judging from the massive silence, there doesn't seem to be
> any strong opinions either way though...
>
>
> // Marcus
>
You're right. Maybe it's a topic for the linuxppc-embedded mailing list, because mostly embedded platforms use the CONFIG_NOT_COHERENT_CACHE option.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH 02/13] IB/ehca: includes
From: Arnd Bergmann @ 2006-08-30 9:43 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, openib-general, Christoph Raisch, Hoang-Nam Nguyen,
Marcus Eder, abergman
In-Reply-To: <OF23CA96AE.C7DBFD52-ONC12571DA.00321849-C12571DA.00324865@de.ibm.com>
On Wednesday 30 August 2006 11:13, Hoang-Nam Nguyen wrote:
> Further comments/suggestions are appreciated!
There are a few places in the driver where you declare
external variables (mostly ehca_module and ehca_debug_level)
from C files instead of a header. This sometimes leads
to bugs when a type changes and is therefore considered
bad style.
ehca_debug_level is already declared in a header so you
should not need any other declaration.
For ehca_module, the usage pattern is very uncommon.
Declaring the structure in a header helps a bit, but I
don't really see the need for this structure at all.
Each member of the struct seems to be used mostly in a
single file, so I would declare it statically in there.
E.g. in drivers/infiniband/hw/ehca/ehca_pd.c, you can do
static struct kmem_cache *ehca_pd_cache;
int ehca_init_pd_cache(void)
{
ehca_pd_cache = kmem_cache_init("ehca_cache_pd",
sizeof(struct ehca_pd), 0, SLAB_HWCACHE_ALIGN,
NULL, NULL);
if (!ehca_pd_cache)
return -ENOMEM;
return 0;
}
void ehca_cleanup_pd_cache(void)
{
if (ehca_pd_cache)
kmem_cache_destroy(ehca_pd_cache);
}
Moreover, for some of your more heavily used caches, you may
want to look into using constructor/destructor calls to
speed up allocation.
Arnd <><
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Mikael Pettersson @ 2006-08-30 9:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Olaf Hering, Nathan Lynch, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <17653.11388.637189.113422@cargo.ozlabs.ibm.com>
Paul Mackerras writes:
> Olaf,
>
> This patch should fix it. The problem was that I was comparing a
> 32-bit quantity with a 64-bit quantity, and consequently time wasn't
> advancing. This makes us use a 64-bit quantity on all platforms,
> which ends up simplifying the code since we can now get rid of the
> tb_last_stamp variable (which actually fixes another bug that Ben H
> and I noticed while going carefully through the code).
>
> This works fine on my G4 tibook. Let me know how it goes on your
> machines.
Thanks. This fixed a kernel hang bug on my G4 eMac with 2.6.18-rc5.
The vanilla kernel ran fine until I tar xvf'd a file from an NFS-mount,
then everything ground to a halt.
/Mikael
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: David Howells @ 2006-08-30 9:09 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-ia64, takata, linux-kernel, paulkf,
linuxppc-embedded
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> --- a/arch/frv/kernel/setup.c
> +++ b/arch/frv/kernel/setup.c
> @@ -31,7 +31,6 @@
> #include <linux/serial_reg.h>
>
> #include <asm/setup.h>
> -#include <asm/serial.h>
> #include <asm/irq.h>
> #include <asm/sections.h>
> #include <asm/pgalloc.h>
Acked-By: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH 02/13] IB/ehca: includes
From: Hoang-Nam Nguyen @ 2006-08-30 9:13 UTC (permalink / raw)
To: abergman, linux-kernel, linuxppc-dev, openib-general
Cc: Christoph Raisch, Marcus Eder
In-Reply-To: <OFED0915E4.3CED6795-ONC12571CE.0053ECB8-C12571CE.0055546A@LocalDomain>
> Christoph Raisch wrote on 18.08.2006 17:35:54:
> we'll change these EDEBs to a wrapper around dev_err, dev_dbg and
> dev_warn as it's done in the mthca driver.
> All EDEB_EN and EDEB_EX will be removed, that type of tracing can be
> done if needed by kprobes.
> There are a few cases where we won't get to a dev, for these few
> places we'll use a simple wrapper around printk, as done in ipoib.
We incorporated those changes throughout ehca code, which is accessible
from
Roland's git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-2.6.19
Further comments/suggestions are appreciated!
Regards
Hoang-Nam Nguyen
^ permalink raw reply
* re: PPC405 system slow boot
From: Arvid Staub @ 2006-08-30 8:20 UTC (permalink / raw)
To: Clint Thomas, linuxppc-embedded
hi!
i've recently had a similar situation with a XC2VP50-based custom board.
There was no SystemACE involved, we load the FPGA via a CPLD/serial =
flash.
the problem resided in the interrupt controller, which was not able to =
enable interrupts due to an error in the MHS file.
you should check that your interrupt controller section includes the =
following parameters:
PARAMETER C_HAS_IPR =3D 1
PARAMETER C_HAS_SIE =3D 1
PARAMETER C_HAS_CIE =3D 1
PARAMETER C_HAS_IVR =3D 1
the intc driver uses SIE and CIE to atomically enable and disable =
interrupts.
when the uartlite interrupt was not enabled, the uartlite driver =
encountered timeouts which caused single characters to appear at the =
serial console, similar to what you described.
hope that helps,
arvid staub
________________________________________
Von: linuxppc-embedded-bounces+arvid.staub=3Dmediornet.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+arvid.staub=3Dmediornet.com@ozlabs.org]=
Im Auftrag von Clint Thomas
Gesendet: Montag, 28. August 2006 21:57
An: linuxppc-embedded@ozlabs.org
Betreff: PPC405 system slow boot
Hey guys,
I've run through the loops to try and figure what could be wrong with =
this system. The board in question is modeled after the Xilinx ML300 =
board. It uses a Xilinx System ACE chip to load a FPGA / Kernel image =
from compact flash. Originally, I was trying to use the CompactFlash as =
the root file system, but because of issues in either the design or =
software, this would only work if SysAce was in polled I/O mode. To =
circumvent this, I built my root filesystem into an initrd image and =
built a single ELF file with the Kernel and RFS, then strapped that to =
the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all of the =
device drivers. However when it gets to the prompt, it starts slowing =
down. Output and input to and from the board becomes very very slow (it =
displays 2 characters roughly every 20 seconds). Originally I believed =
this to be the CPU still polling SystemAce, so I disabled the Linux =
System ACE drivers to remove that as a possibility, however after doing =
this, the problem still persists, even with the RFS in ram! Has anybody =
encountered a similar situation to this before, with possible insight =
towards a solution? Thank you for your time.
=A0
Clinton Thomas
cthomas@soneticom.com
=A0
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Olaf Hering @ 2006-08-30 8:05 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Linus Torvalds, Nathan Lynch,
Linux Kernel Mailing List
In-Reply-To: <17653.11388.637189.113422@cargo.ozlabs.ibm.com>
On Wed, Aug 30, Paul Mackerras wrote:
> This works fine on my G4 tibook. Let me know how it goes on your
> machines.
Works ok on an iBook1.
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:32 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <20060830072948.GE5195@us.ibm.com>
On Wednesday 30 August 2006 09:29, Nishanth Aravamudan wrote:
>
> > Hmm, maybe mlock() policy() is broken.
>
> I took out the mlock() call, and I get the same results, FWIW.
Then it's probably some new problem in hugetlbfs. Does it work with shmfs?
The regression test for hugetlbfs is numactl is unfortunately still disabled.
I need to enable it at some point for hugetlbfs now that it reached mainline.
-Andi
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-30 7:29 UTC (permalink / raw)
To: Andi Kleen; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <200608300919.13125.ak@suse.de>
On 30.08.2006 [09:19:13 +0200], Andi Kleen wrote:
> mous pages.
> >
> > The order is (with necessary params filled in):
> >
> > p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
> >
> > numa_interleave_memory(p, newsize);
> >
> > mlock(p, newsize); /* causes all the hugepages to be faulted in */
> >
> > munlock(p,newsize);
> >
> > From what I gathered from the numa manpages, the interleave policy
> > should take effect on the mlock, as that is "fault-time" in this
> > context. We're forcing the fault, that is.
>
> mlock shouldn't be needed at all here. the new hugetlbfs is supposed
> to reserve at mmap time and numa_interleave_memory() sets a VMA policy
> which will should do the right thing no matter when the fault occurs.
Ok.
> Hmm, maybe mlock() policy() is broken.
I took out the mlock() call, and I get the same results, FWIW.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* booting Linux in Linux using kexec tools
From: Reddy Suneel-ASR125 @ 2006-08-30 7:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
Hi
I am trying to boot Linux (zImage.elf) in Linux using kexec tools.
I am getting the folling crash
sh-2.05b#
sh-2.05b# kexec -e
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Starting new kernel
Bye!
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: 2E5C0020 LR: C000A3CC SP: C8D97DF0 REGS: c8d97d40 TRAP: 0400 Not
taintedMSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c82f84a0[665] 'kexec' THREAD: c8d96000
Last syscall: 88
GPR00: 00000000 C8D97DF0 C82F84A0 2E5C1002 2E5C0000 00000000 00000F35
C0307DBC
GPR08: 2E5C0020 C0350000 00000000 C8D96000 00000000 10030450 00000220
100CBD88
GPR16: FFFFFFFF 00000000 00000000 00000000 00000000 00000000 FFFFFFFF
42202442
GPR24: 100D71C8 100D7508 2E5C1002 C0A8DC80 EE5C0000 2E5C0000 00000000
C0A8DC80
Call trace: [c000a2fc] [c00302d0] [c000206c]
Segmentation fault
sh-2.05b#
I am working on MPC8540 processor.
can any one help me.
Thanks®ards
Suneel
[-- Attachment #2: Type: text/html, Size: 2535 bytes --]
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:16 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, Nishanth Aravamudan, lnxninja, linux-mm
In-Reply-To: <Pine.LNX.4.64.0608291655160.22397@schroedinger.engr.sgi.com>
On Wednesday 30 August 2006 01:57, Christoph Lameter wrote:
> On Tue, 29 Aug 2006, Nishanth Aravamudan wrote:
>
> > I don't know if this is a libnuma bug (I extracted out the code from
> > libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
> > testing purposes, but got the same results) or a NUMA kernel bug (mbind
> > is some hairy code...) or a ppc64 bug or maybe not a bug at all.
> > Regardless, I'm getting somewhat inconsistent behavior. I can provide
> > more debugging output, or whatever is requested, but I wasn't sure what
> > to include. I'm hoping someone has heard of or seen something similar?
>
> Are you setting the tasks allocation policy before the allocation or do
> you set a vma based policy? The vma based policies will only work for
> anonymous pages.
They should work for hugetlb/shmfs too. At least when I originally
wrote it. But the original patch I did for hugetlbfs for that was
never merged and I admit I have never rechecked if it worked with
the patchkit that was merged later. The problem originally was
that hugetlbfs needed to be changed to do allocate-on-demand
instead of allocation-on-mmap, because mbind() comes after mmap()
and when mmap() already allocates it can't work.
-Andi
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:19 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <20060830002110.GZ5195@us.ibm.com>
mous pages.
>
> The order is (with necessary params filled in):
>
> p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
>
> numa_interleave_memory(p, newsize);
>
> mlock(p, newsize); /* causes all the hugepages to be faulted in */
>
> munlock(p,newsize);
>
> From what I gathered from the numa manpages, the interleave policy
> should take effect on the mlock, as that is "fault-time" in this
> context. We're forcing the fault, that is.
mlock shouldn't be needed at all here. the new hugetlbfs is supposed
to reserve at mmap time and numa_interleave_memory() sets a VMA
policy which will should do the right thing no matter when the fault
occurs.
Hmm, maybe mlock() policy() is broken.
-Andi
^ 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