Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
Anantharaman Chetan-W16155 wrote: Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4 FX series FPGA?s, PPC405 processor? Yes, see http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022583.html Note that there are silicon bugs that prevent caches being used in some chips. More specifically, the FX100 FPGA? I don't have one of those, sorry. - aidan
AW: MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
In message CC692F5386B0AA47A62B7484A7CA2B6D02C4CFCC at frmx1.litef.de you wrote: Thanks for answer me. I want to install Xenomai on this mpc8270. Therefor I need 2.6.14 ,because I need the adeos patch. You should be able to use a more recent kenrel tree as well. Looking closer at your problem, it seems obvious where the problem is: ... RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize NFTL driver: nftlcore.c $Revision: 1.97 $, nftlmount.c $Revision: 1.40 $ Oops: kernel access of bad area, sig: 11 [#1] NIP: C0107A14 LR: C0106660 SP: C036FE30 REGS: c036fd80 TRAP: 0300Not tainted ... That's when the kernel attempts to access the flash devices on your board. Please use a later kernel. I just verified that the 2.6.15 kernel (git tag DENX-v2.6.15 in our repo) works fine: Linux version 2.6.15-gref: ref (wd at pollux.denx.de) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #1 Thu Jun 1 02:55:30 MEST 2006 Microsys PM82x PowerPC port arch/ppc/syslib/m82xx_pci.c: The PCI bus is 3750 Mhz. Waiting 0.5 seconds after deasserting RST... Built 1 zonelists Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.0-2006-02-19/ppc_6xx ip=192.168.200.5:192.168.1.1::255.255.0.0:pm827:eth0:off panic=1 console=ttyCPM1,9600 PID hash table entries: 1024 (order: 10, 16384 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 127616k available (1592k kernel code, 412k data, 124k init, 0k highmem) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device :00:00.0 PCI: Cannot allocate resource region 1 of device :00:00.0 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xf0011a80 (irq = 4) is a CPM UART ttyCPM1 at MMIO 0xf0011a90 (irq = 5) is a CPM UART ttyCPM2 at MMIO 0xf0011a00 (irq = 40) is a CPM UART ttyCPM3 at MMIO 0xf0011a20 (irq = 41) is a CPM UART ttyCPM4 at MMIO 0xf0011a40 (irq = 42) is a CPM UART ttyCPM5 at MMIO 0xf0011a60 (irq = 43) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $ Found: Intel 28F640C3B PM82x-0: Found 4 x16 devices at 0x0 in 64-bit bank PM82x flash bank 0: Using static image partition definition Creating 4 MTD partitions on PM82x-0: 0x-0x0004 : U-Boot 0x0004-0x0010 : kernel 0x0010-0x0040 : ramdisk 0x0040-0x0200 : user No valid DiskOnChip devices found eth0: FCC ENET Version 0.3, 00:40:42:81:27:0d mii_reg: 608e78e2 eth0: Phy @ 0x1, type LXT971 (0x001378e2) NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 eth0: config: auto-negotiation on, 100HDX, 10HDX. IP-Config: Complete: device=eth0, addr=192.168.200.5, mask=255.255.0.0, gw=255.255.255.255, host=pm827, domain=, nis-domain=(none), bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath= Looking up port of RPC 13/2 on 192.168.1.1 Looking up port of RPC 15/1 on 192.168.1.1 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 124k init ... Also, the current top-of-tree version (Linux-2.6.17-rc5-g1d475c9f) works fine. Please 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 at denx.de We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.
Can't get CoralP drivers to work (fixed)
Hello guys I had time to dig into the kernel code and I discovered the origin of my problem. As I said in a previous post, we use a custom processor card based on a mpc8270. In the initialisation of our board was missing the following line : conswitchp = dummy_con; That's all ! Now it works fine. I still have a little problem : video output signals seems to be very low. I have to set the maximum contrast and luminosity to see something. I tried on different monitors, the problem is the same. The board is configured to use the rgb analog signals from the coral, not from the dac. Are there any jumpers or register to tweak the video signal levels ? I can't find it in the hardware manual...
memset hangs part way through; called from early_init
Hi All, I'm running a V2Pro-based development board, and I'm working on a linux 2.6.15 port. Currently, the board hangs in the early_init function. Specifically, at the following line: memset_io(PTRRELOC(__bss_start), 0, _end - __bss_start); This memset_io() call eventually calls memset() (from arch/ppc/lib/string.S) to zero the region of memory. Using a BDI2000, I'm able to step through the assembly and see that within memset, it enters a two-instruction loop where it is writing zeros to consecutive memory locations. Everything is going fine, but after 10 or 20 iterations of the loop (it's not consistent), everything blows up. GDB reports the following: -- (gdb) stepi Program received signal SIG110, Real-time event 110. 0xc000b3e8 in memset () (gdb) -- The BDI2000 reports the following: -- *** MMU: address translation for 0xC000B3E8 failed *** MMU: address translation for 0xC000B3E4 failed *** MMU: address translation for 0xC000B3E8 failed *** MMU: address translation for 0xC000B3E4 failed *** MMU: address translation for 0xC000B3B0 failed *** MMU: address translation for 0xDEADBEEF failed *** MMU: address translation for 0xDEADBEEB failed *** MMU: address translation for 0xDEADBEEF failed *** MMU: address translation for 0xDEADBEEB failed *** MMU: address translation for 0x failed *** MMU: address translation for 0xDEADBEEF failed *** MMU: address translation for 0xDEADBEEB failed *** MMU: address translation for 0xDEADBEEF failed *** MMU: address translation for 0xDEADBEEB failed *** MMU: address translation for 0x failed -- Here is my BDI2000 configuration file: -- [INIT] [TARGET] JTAGCLOCK 0 ;use 16 MHz JTAG clock CPUTYPE 405 ;the used target CPU type BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT) BREAKMODE HARD;SOFT or HARD, HARD uses PPC hardware breakpoint STEPMODEHWBP;JTAG or HWBP, HWPB uses one or two hardware breakpoints MMU XLAT 0xC000 ;enable virtual address mode PTBASE 0x00f0 ;address where kernel/user stores pointer to page table STARTUP RESET [HOST] IP 192.9.200.213 FILEppcboot.bin FORMAT BIN 0xfff8 ;0x20 START 0xfff8 ; 0x20 LOADMANUAL ;load code MANUAL or AUTO after reset DEBUGPORT 2001 DUMPdump.bin;Linux: dump.bin must already exist and public writable [FLASH] WORKSPACE 0xd000 CHIPTYPESTRATAX16 BUSWIDTH16 CHIPSIZE0x40 [REGS] IDCR1 0x010 0x011 ;MEMCFGADR and MEMCFGDATA IDCR2 0x012 0x013 ;EBCCFGADR and EBCCFGDATA IDCR3 0x014 0x015 ;KIAR and KIDR FILEreg405gp.def -- Any ideas would be appreciated. Regards, Chris Dumoulin
Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
There are some silicon issues on the PPC405 in V4 with PVR 0x20011430 which are documented in Xilinx solution record 20658. All these issues are fixed in silicon where the PPC405 has a PVR of 0x20011470. Said that it's not true that the caches cannot be used in silicon with PVR 0x20011430. The problem is a corner case which does not show in typical designs. - Peter Aidan Williams wrote: Anantharaman Chetan-W16155 wrote: Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4 FX series FPGA?s, PPC405 processor? Yes, see http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022583.html Note that there are silicon bugs that prevent caches being used in some chips. More specifically, the FX100 FPGA? I don't have one of those, sorry. - aidan ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
On 6/1/06, Peter Ryser peter.ryser at xilinx.com wrote: There are some silicon issues on the PPC405 in V4 with PVR 0x20011430 which are documented in Xilinx solution record 20658. All these issues are fixed in silicon where the PPC405 has a PVR of 0x20011470. Said that it's not true that the caches cannot be used in silicon with PVR 0x20011430. The problem is a corner case which does not show in typical designs. If I understand correctly, the cache issue only shows up with RAM attached to the OPB (instead of PLB). Is that correct? Cheers, g.
Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
We have Linux up and running on the Virtex-4 FX100. The PVR for the PPC405 in all FX100 is 0x20011470. - Peter Anantharaman Chetan-W16155 wrote: Was the port done on a FX100 FPGA? Also, what PVR number does the PPC405 indicate? Thanks, Chetan -Original Message- From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf Of Grant Likely Sent: Wednesday, May 31, 2006 2:35 PM To: Anantharaman Chetan-W16155 Cc: linuxppc-embedded at ozlabs.org Subject: Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC On 5/31/06, Anantharaman Chetan-W16155 Chetan.S.Anantharaman at motorola.com wrote: Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4 FX series FPGA's, PPC405 processor? Linux on the V4-FX is well supported. Xilinx has an app node describing how to modify the linuxppc-2.4 tree to work on the V4-FX. You can find out how to get the tree here: http://www.penguinppc.org/kernel/ I've got both 2.4 2.6 happily running on my ML403 board here. Cheers, g.
Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
It's a little bit more complicated than that but your statement is basically correct. - Peter Grant Likely wrote: On 6/1/06, Peter Ryser peter.ryser at xilinx.com wrote: There are some silicon issues on the PPC405 in V4 with PVR 0x20011430 which are documented in Xilinx solution record 20658. All these issues are fixed in silicon where the PPC405 has a PVR of 0x20011470. Said that it's not true that the caches cannot be used in silicon with PVR 0x20011430. The problem is a corner case which does not show in typical designs. If I understand correctly, the cache issue only shows up with RAM attached to the OPB (instead of PLB). Is that correct? Cheers, g.
Pinned TLB entries with 2.6 linux kernel on PPC4xx
Does the idea of creating pinned TLB entries (ones that will never be overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux kernel? If so, how would this be accomplished? Regards, Chris -- *--Christopher Dumoulin--* Software Team Leader http://ics-ltd.com/ http://ics-ltd.com/ Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON K1J 9G2 (613)749-9241 1-800-267-9794 (USA only) This e-mail is private and confidential and is for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient.
Pinned TLB entries with 2.6 linux kernel on PPC4xx
On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote: Does the idea of creating pinned TLB entries (ones that will never be overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux kernel? If so, how would this be accomplished? 44x kernel already pins some TLB entries, 40x may use this approach to increase performance (I use this in my internal 2.4 tree quite successfully). Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support for 40x, you can look at the implementation there. -- Eugene
memset hangs part way through; called from early_init
In message 200606011700.k51H0WJw014425 at www-webmail1.magma.ca you wrote: Currently, the board hangs in the early_init function. Specifically, at the following line: memset_io(PTRRELOC(__bss_start), 0, _end - __bss_start); ... Any ideas would be appreciated. See http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, Shore Leave, stardate 3025.3
MPC85xx PCI transfer disconnect
I know this is probably a question for Freescale directly, but I thought I would post here to see if anyone else has seen similar issues with the MPC85xx PCI under Linux. I'm using a Freescale MPC85xx (8541) processor and seeing an extreme slowness to the PCI bus. I'm attemping to do 2048 byte PCI burst reads from an external PCI master. So an external chip is the PCI master (initiator) and the MPC85xx is the PCI slave (target) When initiating the PCI burst read, there is a 270 ns delay from the MPC85xx claiming the transaction (DEVSEL# going low) to being ready (TRDY# going low). Then 64 bytes (a single cacheline) are transferred, and TRDY# goes inactive. Next, STOP# goes low, terminating the transfer. I believe this is considered a PCI DISCONNECT type 1 since IRDY# is active the entire time. What I would expect is that the entire 2048 bytes are transferred in one PCI bus mastership, but instead there are several re-arbitrations and long delays in between several 64 byte transfers. Additional info: The PCI bus is 64bit running at 66 MHz. I'm running a modified Linux 2.6.9 kernel (elinos-111). The PCI CCSR piwar1 = 0xa0f4401d. Freescale has an FAQ 21021 that describes having a PCI DISCONNECT 2, which sounds similar to my problem, but I've already confirmed I'm doing what the FAQ suggests (enable prefetching in the piwar register) (http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-21021.xml) Any thoughts/suggestions would be appreciated, Tim
Pinned TLB entries with 2.6 linux kernel on PPC4xx
On Thu, Jun 01, 2006 at 12:51:29PM -0700, Eugene Surovegin wrote: On Thu, Jun 01, 2006 at 03:29:37PM -0400, Chris Dumoulin wrote: Does the idea of creating pinned TLB entries (ones that will never be overwritten) make sense for a PPC4xx (specifically PPC405) 2.6 linux kernel? If so, how would this be accomplished? 44x kernel already pins some TLB entries, 40x may use this approach to increase performance (I use this in my internal 2.4 tree quite successfully). Old 2.4 trees (linuxppc-2.4 or devel_2_4) have TLB pinning support for 40x, you can look at the implementation there. The partial kernel lowmem pinning for ppc405 was deprecated in favor of having all of kernel lowmem covered by large pages and then large TLBs loaded on tlb misses. This is regarding 2.6, of course. It can also be extended to handle arbitrary areas other than kernel lowmem. -Matt
