2009/7/14 javier Martin <javier.martin@xxxxxxxxxxxxxxxxx>: > 2009/7/14 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: >> On Tue, Jul 14, 2009 at 11:05:58AM +0200, javier Martin wrote: >>> 2009/7/14 Daniel Mack <daniel@xxxxxxxx>: >>> > On Tue, Jul 14, 2009 at 09:38:53AM +0200, javier Martin wrote: >>> >> Well, I am using gdb for debugging the kernel through JTAG, >>> >> it currently crashes in function "static int __init ehci_hcd_init(void)" >>> >> when executing line "retval = platform_driver_register(&PLATFORM_DRIVER);". >>> > >>> > The platform_driver's probe function is also called. Set a breakpoint at >>> > ehci_mxc_drv_probe(), the real crash must be there or in one the >>> > functions called. >>> > >>> > Daniel >>> > >>> > >>> Yeah, you are right, the hierarchy is as follows: >>> >>> ehci_mxc_setup() -> ehci_reset() -> ehci_hub_control() >>> >>> In "ehci_hub_control" it crashes in the following "ehci_readl": >>> >>> case USB_PORT_FEAT_POWER: >>> if (HCS_PPC (ehci->hcs_params)) >>> ehci_writel(ehci, >>> temp & ~(PORT_RWC_BITS | PORT_POWER), >>> status_reg); >>> break; >>> >>> Where "status_reg" is 0xc4846184, it seems this is a wrong value >>> because base address of USB in i.mx27 is 0x10024000. >>> What do you think? >> >> 0xc4846184 is the kernel virtual address, not the physical address. The >> value seems sane. >> >> Sascha >> >> >> -- >> Pengutronix e.K. | | >> Industrial Linux Solutions | http://www.pengutronix.de/ | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | >> > > You are right, silly me, I didn't notice the "ioremap". That is not > the problem at all. > > However, I have disassembled the code which belongs to the crashing > function which is the following: > >>> ehci_writel(ehci, >>> temp & ~(PORT_RWC_BITS | PORT_POWER), >>> status_reg); > > Dump of assembler code from 0xc0125a5c to 0xc0125b5c: > 0xc0125a5c <ehci_hub_control+440>: bicne r3, r1, #4096 ; 0x1000 > 0xc0125a60 <ehci_hub_control+444>: bicne r3, r3, #42 ; 0x2a > 0xc0125a64 <ehci_hub_control+448>: strne r3, [r4] > > First two instructions are executed properly. It is the "strne" > instruction which fails. > Final register values are: > r3 = 0x80000000 > r4 = 0xc4846184 > > So it is trying to store the value 0x80000000 in the address > 0xc4846184 which is > the PORTSC1 register (physical address 0x10024168). When executing > this instruction > the system crashes as previously explained. > > So, I have enabled a breakpoint in this assembler instruction so that > I can let the system > in the same state. Then I try the following openOCD commands: > > * Read, write, read TXFILLTUNING register using physical addresses. > > (gdb) mon arm926ejs mdw_phys 0x10024164 > 0x10024164: 00020000 > (gdb) mon arm926ejs mww_phys 0x10024164 0x00040000 > (gdb) mon arm926ejs mdw_phys 0x10024164 > 0x10024164: 00040000 > > * Read, write, read TXFILLTUNING register using virtual addresses. > > (gdb) mon mdw 0xc4846164 1 > 0xc4846164: 00020000 > (gdb) mon mww 0xc4846164 0x00040000 > (gdb) mon mdw 0xc4846164 1 > 0xc4846164: 00040000 > > > * Read, write, read PORTSC1 register using physical addresses. > > (gdb) mon arm926ejs mdw_phys 0x10024184 > 0x10024184: 80000000 > (gdb) mon arm926ejs mww_phys 0x10024184 0x80000000 > memory write caused data abort (address: 0x10024184, size: 0x4, count: 0x1) > error: access caused data abort, system possibly corrupted > (gdb) mon arm926ejs mdw_phys 0x10024184 > memory read caused data abort (address: 0x10024184, size: 0x4, count: 0x1) > error: access caused data abort, system possibly corrupted > 0x10024184: c4846140 > > * Read, write, read PORTSC1 register using virtual addresses. > > (gdb) mon mdw 0xc4846184 1 > 0xc4846184: 80000000 > (gdb) mon mww 0xc4846184 0x80000000 > memory write caused data abort (address: 0xc4846184, size: 0x4, count: 0x1) > Runtime error, file "command.c", line 469: > (gdb) mon mdw 0xc4846184 1 > memory read caused data abort (address: 0xc4846184, size: 0x4, count: 0x1) > Runtime error, file "command.c", line 469: > > > I don't know why the write access to PORTSC1 register fails, while the one to > TXFILLTUNING success. They are both registers from the USB. > This would also discard a problem with the "ahb_clk". > > Any suggestion please? The problem was an issue with chip select line, which is connected to a GPIO in my board. I was not using GPIO interface properly. Now it has been solved. So, your patches also work on i.mx27. I will send a patch with the changes needed in "/arch/arm/mach-mx2/devices.c" and "/arch/arm/mach-mx2/clock_imx27.c" to add platform devices and resources in i.mx27. Who should I send this patch to, linux-usb or linux-arm-kernel mantainer? Thanks. -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
