Another interesting information: when I remove the Xenomai from the compilation options, and still letting the i-pipe compilation, the boot starts correctly.
Is it correct? Flavio de Castro Alves Filho Phi Innovations - Embedded Software Services www.phiinnovations.com Phone: +55 11 84 94 56 76 Skype: flavio.de.castro.alves.filho 2010/1/8 Flavio de Castro Alves Filho <[email protected]> > Hello, > > The functions level_egde_irq and __ipipe_ack_edge_irq are not called during > boot process. > > I'm sending attached the boot log with my traces separated > > irq = 21 > __ipipe_mach_irq_mux_p false > > Linux version 2.6.29-rc8-davinci1 (fla...@flavio-laptop) (gcc version > 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #57 PREEMPT Fri Jan 8 13:58:39 BRST > 2010 > > CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 > CPU: VIVT data cache, VIVT instruction cache > Machine: DaVinci DA850 EVM > Memory policy: ECC disabled, Data cache writeback > DA0850 variant 0x0 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 > Kernel command line: mem=32M console=ttyS2,115200n8 root=/dev/ram0 rw > initrd=0xc1180000,4M ip=10.1.1.2:10.1.1.1 > > PID hash table entries: 128 (order: 7, 512 bytes) > I-pipe 1.13-03: pipeline enabled. > Console: colour dummy device 80x30 > Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) > Memory: 32MB = 32MB total > Memory: 24236KB available (3592K code, 367K data, 148K init) > Calibrating delay loop... 86.63 BogoMIPS (lpj=433152) > > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > net_namespace: 880 bytes > NET: Registered protocol family 16 > Pin I2C1_SCL already used for UART2_RXD. > Pin I2C1_SDA already used for UART2_TXD. > DaVinci: 144 gpio irqs > bio: create slab <bio-0> at 0 > SCSI subsystem initialized > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > musb_hdrc: version 6.0, cppi4.1-dma, host, debug=0 > Waiting for PHY clock good... > musb_hdrc: USB Host mode controller at fee00000 using DMA, IRQ 58 > musb_hdrc musb_hdrc: MUSB HDRC host driver > musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 1024 (order: 1, 8192 bytes) > TCP bind hash table entries: 1024 (order: 0, 4096 bytes) > TCP: Hash tables configured (established 1024 bind 1024) > TCP reno registered > NET: Registered protocol family 1 > checking if image is initramfs...it isn't (no cpio magic); looks like an > initrd > Freeing initrd memory: 4096K > I-pipe: Domain Xenomai registered. > Xenomai: hal/arm started. > Xenomai: real-time nucleus v2.4.9.1 (Big Bad Moon) loaded. > Xenomai: starting native API services. > Xenomai: starting POSIX services. > Xenomai: starting RTDM services. > msgmni has been set to 55 > io scheduler noop registered > io scheduler anticipatory registered (default) > Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled > serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A > serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A > serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A > console [ttyS2] enabled > brd: module loaded > davinci_emac_probe: using random MAC addr: fe:1e:01:fe:ce:b4 > > emac-mii: probed > dm9000 Ethernet Driver, V1.31 > console [netcon0] enabled > netconsole: network logging started > Linux video capture interface: v2.00 > Driver 'sd' needs updating - please use bus_type methods > davinci_nand davinci_nand.1: Using 4-bit hardware ECC - Syndrome > No NAND device found!!! > > irq = 12 > __ipipe_mach_irq_mux_p false > dma_ccerr_handler > IRQ_HANDLED > irq = 12 > __ipipe_mach_irq_mux_p false > dma_ccerr_handler > IRQ_HANDLED > > m25p80 spi1.0: m25p64 (8192 Kbytes) > Creating 3 MTD partitions on "m25p80": > 0x000000000000-0x000000040000 : "U-Boot" > 0x000000040000-0x000000044000 : "U-Boot Environment" > Moving partition 2: 0x000000044000 -> 0x000000050000 > 0x000000050000-0x000000800000 : "Linux" > dm_spi.1: davinci SPI Controller driver at 0xfef0e000 (irq = 56) use_dma=1 > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > usb1 usb1: DA8XX OHCI > usb1 usb1: new USB bus registered, assigned bus number 2 > usb1 usb1: irq 59, io mem 0x01e25000 > > <some time later ... a couple of minutes> > > irq = 22 > __ipipe_mach_irq_mux_p false > irq = 22 > __ipipe_mach_irq_mux_p false > > > Best regards, > > Flavio > > > Flavio de Castro Alves Filho > Phi Innovations - Embedded Software Services > www.phiinnovations.com > Phone: +55 11 84 94 56 76 > Skype: flavio.de.castro.alves.filho > > > 2010/1/8 Gilles Chanteperdrix <[email protected]> > >> Flavio de Castro Alves Filho wrote: >> > In fact, >> > >> > The problem is not really related to the other timer, I believe. >> > >> > Before the timer with irq 22 is called, another irq is called by >> > __ipipe_grab_irq(): the irq number 12 (IRQ_DA8XX_CCERRINT). >> > >> > Now I'm looking for the place there this irq number is passed. >> > >> > And thank you for this important information about the timers. >> >> I think your problem really is that irq22 uses handle_edge_irq, somehow. >> Could you check whether this is the case, for instance by putting a >> printk in the __ipipe_ack_edge_irq function, file kernel/irq/chip.c ? >> >> -- >> Gilles. >> > >
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
