Linux 2.6 PCI Device Driver on Virtex 4
I have spent the past few months slowly trying to get a PCI design with Linux 2.6 on the Virtex 4. I have been able to overcome some of the hurdles; however, I am still unable to boot up a working system. I am using PPC.I have implemented Xilinx's board support package including xparameter head file, ml410 early boot files, pci support files, Board initialization file, did board specific setup, and fixed some bugs in its call tree. I have attached my booting message in this mail. As you can see, I am stuck at "[ 11.805382] Freeing unused kernel memory: 100k init" . Usually it's the last step before the kernel starts root file system. I am sure my ramdisk and root file system were both working OK. My naive thought is that the kernel could not register serial port successfully (see time stamp [ 5.965954]). As a result, ttyS0 was not able to run and display messages after starting ramdisk. It's also interesting to see my ml410 board respond me with a "ml300" id. My booting message was saying: pci_scan: bus 0, device 8, id 030010ee "10ee" is the vendor id for xilinx while "0300" is the device id which I think might represent ml300. Does Xilinx forget to refresh its rom? Here is my environment and tools: -- Xilinx ML410 Rev C -- Xilinx EDK 9.2i -- Secret lab Linux v2.6 originally configured as platform Xilinx ML403 And my booting message: --- Xilinx ML410 Board-Specific Initialization: ppb_init: dev = 9, id = ac23104c pci_scan: bus 0, device 1, id 545110b9 pci_scan: bus 0, device 2, id 153310b9 pci_scan: bus 0, device 3, id 545710b9 pci_scan: bus 0, device 8, id 030010ee pci_scan: bus 0, device 9, id ac23104c pci_scan: bus 0, device 12, id 710110b9 pci_scan: bus 0, device 15, id 523710b9 sio_init: Device ID = 53 15, Revision = f3. sio_init: LPT1 base = 0x0378, irq = 5. sio_init: COM1 base = 0x03f8, irq = 4. sio_init: COM2 base = 0x02f8, irq = 3. sio_init: KBC irq = 1, PS2 irq = 1. sio_init: Super I/O initialization complete. loaded at: 0040 006C21B4 board data at: 006C0124 006C01A0 relocated to: 00405154 004051D0 zimage at: 00406215 004EFDAA initrd at: 004F 006BFDB0 avail ram: 006C3000 0800 Linux/PPC load: console=ttyS0,9600 ip=off root=/dev/ram Uncompressing Linux...done. Now booting the kernel [0.00] Linux version 2.6.23-rc2-g0d62d8a8-dirty ([EMAIL PROTECTED] homer.uncc.edu) (gcc version 4.2.1) #190 Thu Mar 28 [0.00] Xilinx ML40x Reference System (Virtex-4 FX) [0.00] Port by MontaVista Software, Inc. ([EMAIL PROTECTED]) [0.00] Zone PFN ranges: [0.00] DMA 0 ->32768 [0.00] Normal 32768 ->32768 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 ->32768 [0.00] Built 1 zonelists in Zone order. Total pages: 32512 [0.00] Kernel command line: console=ttyS0,9600 ip=off root=/ dev/ram [0.00] Xilinx INTC #0 at 0x4120 mapped to 0xE7FED000 [0.00] PID hash table entries: 512 (order: 9, 2048 bytes) [0.000175] Console: colour dummy device 80x25 [0.000241] console [ttyS0] enabled [1.382947] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [1.466045] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [1.572643] Memory: 125852k available (1480k kernel code, 496k data, 100k init, 0k highmem) [1.764350] Mount-cache hash table entries: 512 [1.827727] PCI: Probing PCI hardware [1.906477] ppc405_map_irq: bus 0 idsel 1 pin 1, res = 31 [1.970528] ppc405_map_irq: bus 0 idsel 2 pin 1, res = 31 [2.035157] ppc405_map_irq: bus 0 idsel 3 pin 1, res = 31 [2.099646] ppc405_map_irq: bus 0 idsel 8 pin 1, res = 31 [2.164225] ppc405_map_irq: bus 0 idsel 9 pin 1, res = 31 [2.228787] ppc405_map_irq: bus 0 idsel 11 pin 1, res = 31 [2.294400] ppc405_map_irq: bus 0 idsel 12 pin 1, res = 31 [2.360031] ppc405_map_irq: bus 0 idsel 15 pin 1, res = 31 [2.441645] SCSI subsystem initialized [2.487503] usbcore: registered new interface driver usbfs [2.553907] usbcore: registered new interface driver hub [2.617790] usbcore: registered new device driver usb [2.687574] checking if image is initramfs...it isn't (no cpio magic); looks like an initrd [4.548936] Freeing initrd memory: 1855k freed [4.606889] io scheduler noop registered [4.653232] io scheduler anticipatory registered (default) [4.718790] io scheduler deadline registered [4.769907] io scheduler cfq registered [4.815634] Activating ISA DMA hang workarounds. [5.667502] :00:0f.0 OHCI: BIOS handoff failed (BIOS bug ?) [5.798505] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled [5.892194] serial8250: ttyS0 at MMIO 0x0 (irq = 12) is a 16550A [5.965954] Couldn't register serial port :00:03.0: -28
RE: Network Bad Kernel Access
I'm not using DRE and CSUM yet. I have seen some weirdness similar to that but hard to reproduce reliably to chase it. I tend to see it with heavy traffic also, so maybe it's not related to DRE & CSUM. I am running DMA. -- John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Likely Sent: Friday, March 28, 2008 5:25 PM To: [EMAIL PROTECTED]; Stephen Neuendorffer; John Linn Cc: linuxppc-embedded@ozlabs.org Subject: Re: Network Bad Kernel Access On Sun, Aug 26, 2007 at 7:00 PM, <[EMAIL PROTECTED]> wrote: > I am having a problem with my network. I am using a V4FX12 running linux > 2.6.21 with the TEMAC. I am running the PPC at 300 MHz and the TEMAC is > configured for DMA and DRE on the Xmit and the Recv. I have tried varying > the FIFO depth and enabling/disabling the checksum offloading. All produce > the error below when under heavy network traffic (specifically sending data > from the PPC). Has anybody seen this? It seems like I am overflowing some > memory, but I am not sure what/where to increase it. I'm seeing the same behavior on my platform except that I get it almost immediately after bringing up the Ethernet interface. I've only just started to debug this. The bug showed up when DMA+DRE+CSUM were enabled on the core. Stephen, John; does any of this look familiar? Cheers, g. > > Thanks, > Glenn > > > > [ 484.696738] Oops: kernel access of bad area, sig: 11 [#1] > [ 484.761286] NIP: c00e1ef4 LR: c00cfec0 CTR: c00cfe34 > [ 484.820650] REGS: c0483b10 TRAP: 0300 Not tainted (2.6.21) > [ 484.889378] MSR: 00029030 CR: 93005999 XER: e000 > [ 484.965410] DAR: bb857caf, DSISR: > [ 485.014365] TASK = c0648b60[129] 'rcS' THREAD: c0482000 > [ 485.074765] GPR00: c04fdfb8 c0483bc0 c0648b60 bb857c2b c04fd9a0 c0483bcc > 0400 ff107ac0 > [ 485.174747] GPR08: 000f c04fdfb8 c04d2478 00010001 00648d10 1003c2e0 > 0001 > [ 485.274732] GPR16: 0003 c0483ed8 4fd8 05b4 05b4 > 0001679c > [ 485.374716] GPR24: 7ff8b398 3002afe0 000f c04d2000 c04d23b8 c06bbe60 > 0003 c04d2320 > [ 485.476784] NIP [c00e1ef4] kfree_skb+0x8/0x3c > [ 485.528858] LR [c00cfec0] SgSendHandlerBH+0x8c/0x1cc > [ 485.588223] Call Trace: > [ 485.617389] [c0483bc0] [c00cfec0] SgSendHandlerBH+0x8c/0x1cc > (unreliable) > [ 485.698628] [c0483bf0] [c0019218] tasklet_action+0x90/0xd4 > [ 485.764241] [c0483c00] [c0018ebc] __do_softirq+0x64/0xd0 > [ 485.827772] [c0483c20] [c00064a8] do_softirq+0x40/0x58 > [ 485.889221] [c0483c30] [c0018f74] irq_exit+0x38/0x48 > [ 485.948586] [c0483c40] [c0006450] do_IRQ+0x88/0xa0 > [ 486.005868] [c0483c50] [c00032d8] ret_from_except+0x0/0x18 > [ 486.071483] [c0483d10] [c0483d00] 0xc0483d00 > [ 486.122516] [c0483d20] [c00e17d4] __alloc_skb+0x48/0x11c > [ 486.186048] [c0483d40] [c0109218] tcp_sendmsg+0x1ac/0xc40 > [ 486.250621] [c0483db0] [c0126b58] inet_sendmsg+0x60/0x74 > [ 486.314152] [c0483dd0] [c00dcf34] sock_aio_write+0xe0/0xfc > [ 486.379765] [c0483e30] [c0050910] do_sync_write+0xb8/0x10c > [ 486.445381] [c0483ef0] [c0050a40] vfs_write+0xdc/0x10c > [ 486.506829] [c0483f10] [c0050b48] sys_write+0x4c/0x8c > [ 486.567236] [c0483f40] [c0002c90] ret_from_syscall+0x0/0x3c > [ 486.633888] Instruction dump: > [ 486.669300] 0f00 7fe3fb78 7d6803a6 4e800021 80010014 7fe3fb78 > 7c0803a6 bbc10008 > [ 486.761992] 38210010 4bfffe78 2c03 4d820020 <80030084> 39230084 > 2f81 409e0008 > [ 486.858162] Kernel panic - not syncing: Aiee, killing interrupt handler! > [ 486.938382] Rebooting in 180 seconds.. > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Network Bad Kernel Access
On Sun, Aug 26, 2007 at 7:00 PM, <[EMAIL PROTECTED]> wrote: > I am having a problem with my network. I am using a V4FX12 running linux > 2.6.21 with the TEMAC. I am running the PPC at 300 MHz and the TEMAC is > configured for DMA and DRE on the Xmit and the Recv. I have tried varying > the FIFO depth and enabling/disabling the checksum offloading. All produce > the error below when under heavy network traffic (specifically sending data > from the PPC). Has anybody seen this? It seems like I am overflowing some > memory, but I am not sure what/where to increase it. I'm seeing the same behavior on my platform except that I get it almost immediately after bringing up the Ethernet interface. I've only just started to debug this. The bug showed up when DMA+DRE+CSUM were enabled on the core. Stephen, John; does any of this look familiar? Cheers, g. > > Thanks, > Glenn > > > > [ 484.696738] Oops: kernel access of bad area, sig: 11 [#1] > [ 484.761286] NIP: c00e1ef4 LR: c00cfec0 CTR: c00cfe34 > [ 484.820650] REGS: c0483b10 TRAP: 0300 Not tainted (2.6.21) > [ 484.889378] MSR: 00029030 CR: 93005999 XER: e000 > [ 484.965410] DAR: bb857caf, DSISR: > [ 485.014365] TASK = c0648b60[129] 'rcS' THREAD: c0482000 > [ 485.074765] GPR00: c04fdfb8 c0483bc0 c0648b60 bb857c2b c04fd9a0 c0483bcc > 0400 ff107ac0 > [ 485.174747] GPR08: 000f c04fdfb8 c04d2478 00010001 00648d10 1003c2e0 > 0001 > [ 485.274732] GPR16: 0003 c0483ed8 4fd8 05b4 05b4 > 0001679c > [ 485.374716] GPR24: 7ff8b398 3002afe0 000f c04d2000 c04d23b8 c06bbe60 > 0003 c04d2320 > [ 485.476784] NIP [c00e1ef4] kfree_skb+0x8/0x3c > [ 485.528858] LR [c00cfec0] SgSendHandlerBH+0x8c/0x1cc > [ 485.588223] Call Trace: > [ 485.617389] [c0483bc0] [c00cfec0] SgSendHandlerBH+0x8c/0x1cc > (unreliable) > [ 485.698628] [c0483bf0] [c0019218] tasklet_action+0x90/0xd4 > [ 485.764241] [c0483c00] [c0018ebc] __do_softirq+0x64/0xd0 > [ 485.827772] [c0483c20] [c00064a8] do_softirq+0x40/0x58 > [ 485.889221] [c0483c30] [c0018f74] irq_exit+0x38/0x48 > [ 485.948586] [c0483c40] [c0006450] do_IRQ+0x88/0xa0 > [ 486.005868] [c0483c50] [c00032d8] ret_from_except+0x0/0x18 > [ 486.071483] [c0483d10] [c0483d00] 0xc0483d00 > [ 486.122516] [c0483d20] [c00e17d4] __alloc_skb+0x48/0x11c > [ 486.186048] [c0483d40] [c0109218] tcp_sendmsg+0x1ac/0xc40 > [ 486.250621] [c0483db0] [c0126b58] inet_sendmsg+0x60/0x74 > [ 486.314152] [c0483dd0] [c00dcf34] sock_aio_write+0xe0/0xfc > [ 486.379765] [c0483e30] [c0050910] do_sync_write+0xb8/0x10c > [ 486.445381] [c0483ef0] [c0050a40] vfs_write+0xdc/0x10c > [ 486.506829] [c0483f10] [c0050b48] sys_write+0x4c/0x8c > [ 486.567236] [c0483f40] [c0002c90] ret_from_syscall+0x0/0x3c > [ 486.633888] Instruction dump: > [ 486.669300] 0f00 7fe3fb78 7d6803a6 4e800021 80010014 7fe3fb78 > 7c0803a6 bbc10008 > [ 486.761992] 38210010 4bfffe78 2c03 4d820020 <80030084> 39230084 > 2f81 409e0008 > [ 486.858162] Kernel panic - not syncing: Aiee, killing interrupt handler! > [ 486.938382] Rebooting in 180 seconds.. > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
video driver problems on set top box board
I am using a set top box board : MB442 based on STi7109 chip. I use STAPI (drivers provided by ST) with STlinux kernell. I have some problems with a module (named mme_host) which must be inserted with arguments (insmod mme_host.ko transport0=). This operation causes the following error : insmod: error inserting '/home/bakhaled/modules/mme/mme_host.ko': -1 Operation not permitted I tried to insert the module without arguments (insmod mme_host.ko) and this was successful. But when I try to run a test program for video , after inserting that mme module without arguments, the system crash down. (don't execute console commands). Has any one experienced this type of problems? Have you any solutions ? -- View this message in context: http://www.nabble.com/video-driver-problems-on-set-top-box-board-tp16354810p16354810.html Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
video driver problems on set top box board
I am working ST set top box board and I need help to resolve some problems. if you 're working on set top box or you have experience with them these are more detailed informations: I am using a set top box board : STB442 based on STi7109 chip. I use STAPI (drivers provided by ST) with STlinux kernell. I have some problems with a module (named mme_host) which must be inserted with arguments (insmod mme_host.ko transport0=). This operation causes the following error : insmod: error inserting '/home/bakhaled/modules/mme/mme_host.ko': -1 Operation not permitted I tried to insert the module without arguments (insmod mme_host.ko) and this was successful. But when I try to run a test program for video , after inserting that mme module without arguments, the system crash down. (don't execute console commands). Has any one experienced this type of problems? Have you any solutions ? -- View this message in context: http://www.nabble.com/video-driver-problems-on-set-top-box-board-tp16352982p16352982.html Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express problem
> > On Mar 25, 2008, at 8:03 AM, Marco Stornelli wrote: >> Kumar Gala ha scritto: >>> On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote: Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a "machine check exception: transfer error ack signal" 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. >>> Where are you loading the FPGA microcode (linux, u-boot)? Also, is >>> the FPGA the only device connected over PCIe? >>> - k >> I load the FPGA with JTAG and with a Xilinx program without a >> specific linux driver or u-boot. Yes, it is the only device >> connected over PCIe. > > The issue may be related to the PCIe link training. Are you able to > access the FPGA in u-boot? Can you try reseting the PCIe controller > after you've loaded up the FPGA (see u-boot code in drivers/pci/ > fsl_pci_init.c and look for CONFIG_FSL_PCIE_RESET) > > - k > Ok I can try but I'm using the U-Boot 1.3.0 provided by Freescale with the board, so I have to change the firmware, updating the U-Boot to the version 1.3.2 to use CONFIG_FSL_PCIE_RESET. However, I've had the same idea, but I check (with a warning) this case in the kernel function fsl_check_pcie_link() (where the kernel check the value of LTSSM) but I've never seen the warning during the start-up. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
