Clinton Thomas
cthomas@soneticom.com


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org=

https://oz=
labs.org/mailman/listinfo/linuxppc-embedded

= ------_=_NextPart_001_01C6CE1A.120E23B4-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Soneticom.com (soneticom.com [209.114.210.150]) by ozlabs.org (Postfix) with ESMTP id 1C87B67B72 for ; Wed, 6 Sep 2006 23:28:36 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D1B8.59320664" Subject: RE: PPC405 system slow boot Date: Wed, 6 Sep 2006 09:28:32 -0400 Message-ID: <3C02138692C13C4BB675FE7EA24095291C3C0F@bluefin.Soneticom.local> From: "Clint Thomas" To: List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D1B8.59320664 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Actually, we figured out what was going on. Apparently we left one of the interrupt lines disconnected from the CPU in the FPGA design. Thanks for all the help guys, I really do appreciate it. Clint Thomas ________________________________ From: Clint Thomas=20 Sent: Friday, September 01, 2006 6:58 PM To: linuxppc-embedded@ozlabs.org Cc: 'Peter Ryser '; Jason Lamb Subject: RE: PPC405 system slow boot The xparameters.h file is generated by the Xilinx EDK for our FPGA, so I don't see how there could be a mismatch. Using Chipscope, we were able to find that the interrupt controller is triggered on kernel initialization, but after the kernel has finished loading, the system moves to a snail's pace at login.=20 =20 Does Linux use a different set of code to handle the UART, INTC, etc. after the kernel is loaded? The system appears to work perfectly up until after the kernel is done loading. ________________________________ From: Peter Ryser [mailto:peter.ryser@xilinx.com]=20 Sent: Monday, August 28, 2006 8:45 PM To: Clint Thomas Cc: linuxppc-embedded@ozlabs.org Subject: Re: PPC405 system slow boot Clint, check the interrupt sub-system of your design. What you describe typically happens when the PPC does not get any interrupts from the UART. It's most likely a mismatch between your hardware and the xparameters.h. - Peter Clint Thomas wrote:=20 Hey guys, =09 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. =09 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. =20 Clinton Thomas cthomas@soneticom.com =20 =09 ________________________________ _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ------_=_NextPart_001_01C6D1B8.59320664 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Actually, we figured out what was going on. = Apparently we=20 left one of the interrupt lines disconnected from the CPU in the FPGA = design.=20 Thanks for all the help guys, I really do appreciate it.

Clint=20 Thomas

From: Clint Thomas
Sent: = Friday,=20 September 01, 2006 6:58 PM
To:=20 linuxppc-embedded@ozlabs.org
Cc: 'Peter Ryser '; Jason=20 Lamb
Subject: RE: PPC405 system slow boot

The xparameters.h file is generated by the = Xilinx EDK=20 for our FPGA, so I don't see how there could be a mismatch. Using = Chipscope, we=20 were able to find that the interrupt controller is triggered on kernel=20 initialization, but after the kernel has finished loading, the system = moves to a=20 snail's pace at login.

Does Linux use a different set of code to = handle the=20 UART, INTC, etc. after the kernel is loaded? The system appears to work=20 perfectly up until after the kernel is done = loading.

From: Peter Ryser=20 [mailto:peter.ryser@xilinx.com]
Sent: Monday, August 28, 2006 = 8:45=20 PM
To: Clint Thomas
Cc:=20 linuxppc-embedded@ozlabs.org
Subject: Re: PPC405 system slow=20 boot

Clint,

check the interrupt sub-system of your design. = What you=20 describe typically happens when the PPC does not get any interrupts from = the=20 UART. It's most likely a mismatch between your hardware and the=20 xparameters.h.

- Peter

Clint Thomas wrote:=20

Hey=20 guys,

I've run through the loops to try and figure what could = be wrong=20 with this system. The board in question is modeled after the Xilinx = ML300=20 board. It uses a Xilinx System ACE chip to load a FPGA / Kernel image = from=20 compact flash. Originally, I was trying to use the CompactFlash as the = root=20 file system, but because of issues in either the design or software, = this=20 would only work if SysAce was in polled I/O mode. To circumvent this, = I built=20 my root filesystem into an initrd image and built a single ELF file = with the=20 Kernel and RFS, then strapped that to the FPGA bit file to make a = single=20 FPGA/Kernel/RFS SysAce file.

Upon decompression, the Linux = kernel boots=20 quickly and loads all of the device drivers. However when it gets to = the=20 prompt, it starts slowing down. Output and input to and from the board = becomes=20 very very slow (it displays 2 characters roughly every 20 seconds). = Originally=20 I believed this to be the CPU still polling SystemAce, so I disabled = the Linux=20 System ACE drivers to remove that as a possibility, however after = doing this,=20 the problem still persists, even with the RFS in ram! Has anybody = encountered=20 a similar situation to this before, with possible insight towards a = solution?=20 Thank you for your time.

Clinton Thomas
cthomas@soneticom.com


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org=

https://oz=
labs.org/mailman/listinfo/linuxppc-embedded

= ------_=_NextPart_001_01C6D1B8.59320664--