On Sun, Sep 23, 2012 at 12:01 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > cc Santosh > > Hi Igor, > > I regret the delay in responding, > > On Fri, 7 Sep 2012, Igor Grinberg wrote: > > > On 09/05/12 18:44, Paul Walmsley wrote: > > > > > * CM-T3517: L3 in-band error with USB OTG during boot > > > - Cause unknown; longstanding issue; does not occur on the 3517EVM > > > > We see this problem on several cm-t3517, but not all of them. > > There's probably a dependency on the bootloader or X-Loader. > > > It looks something like: > > --------------------cut---------------------------- > > NET: Registered protocol family 16 > > GPMC revision 5.0 > > gpmc: irq-20 could not claim: err -22 > > OMAP GPIO hardware version 2.5 > > In-band Error seen by USB_OTG at address 0 > > That tag "USB_OTG" above isn't 100% accurate for AM3517/3505, by the way. > omap_l3_smx.c doesn't have a correct initiator map for those chips. The > offender could be USBOTG, but it could also be any other initiator in the > "IP subsystem", such as Camera/VPFE or EMAC. Table 5-18 "InitiatorID > Definition" in the AM35x TRM vB (SPRUGR0B) lists these. > That is possible. Will have a look at AMXX initiator map. > As far as I know, the message means that some module in the IPSS tried to > initiate an L3 interconnect transaction, but that it failed. Probably the > IPSS isn't clocked. > In-band error is reported to an initiator typically for the out of band access. Probably address space is not accessible either because the IP(ISS) as per Pauls TRM decoding either still not out of reset or not clocked yet. If the clocking itself was the issue at least address space should have been valid and there I expect a different error. > > ------------[ cut here ]------------ > > WARNING: at > > /home/lifshitz/workroot/git-repo/linux-cm-t3x/arch/arm/mach-omap2/omap_l3_smx.c:162 > > omap3_l3_app_irq+0xdc/0x120() > > Modules linked in: > > [<c001ad08>] (unwind_backtrace+0x0/0xf4) from [<c003f670>] > > (warn_slowpath_common+0x4c/0x64) > > [<c003f670>] (warn_slowpath_common+0x4c/0x64) from [<c003f6a4>] > > (warn_slowpath_null+0x1c/0x24) > > [<c003f6a4>] (warn_slowpath_null+0x1c/0x24) from [<c0033af0>] > > (omap3_l3_app_irq+0xdc/0x120) > > [<c0033af0>] (omap3_l3_app_irq+0xdc/0x120) from [<c008b8bc>] > > (handle_irq_event_percpu+0xac/0x298) > > [<c008b8bc>] (handle_irq_event_percpu+0xac/0x298) from [<c008bafc>] > > (handle_irq_event+0x54/0x74) > > [<c008bafc>] (handle_irq_event+0x54/0x74) from [<c008e290>] > > (handle_level_irq+0xc4/0x118) > > [<c008e290>] (handle_level_irq+0xc4/0x118) from [<c008b3ac>] > > (generic_handle_irq+0x2c/0x44) > > [<c008b3ac>] (generic_handle_irq+0x2c/0x44) from [<c001500c>] > > (handle_IRQ+0x60/0x80) > > [<c001500c>] (handle_IRQ+0x60/0x80) from [<c00085ec>] > > (omap3_intc_handle_irq+0x60/0x74) > > [<c00085ec>] (omap3_intc_handle_irq+0x60/0x74) from [<c04e3100>] > > (__irq_svc+0x40/0x74) > > Exception stack(0xcf02de00 to 0xcf02de48) > > de00: 00000000 0000000a 00000000 00000021 c074bcac cf046280 0000000a > > 60000013 > > de20: c074bcdc c070020c 00010000 00000000 00000000 cf02de48 00000000 > > c008c988 > > de40: 40000013 ffffffff > > [<c04e3100>] (__irq_svc+0x40/0x74) from [<c008c988>] > > (__setup_irq+0x2a8/0x404) > > [<c008c988>] (__setup_irq+0x2a8/0x404) from [<c008cd18>] > > (request_threaded_irq+0xe8/0x13c) > > [<c008cd18>] (request_threaded_irq+0xe8/0x13c) from [<c06c3d24>] > > (omap3_l3_probe+0x10c/0x16c) > > [<c06c3d24>] (omap3_l3_probe+0x10c/0x16c) from [<c033586c>] > > (platform_drv_probe+0x18/0x1c) > > [<c033586c>] (platform_drv_probe+0x18/0x1c) from [<c0334414>] > > (really_probe+0xac/0x1c8) > > [<c0334414>] (really_probe+0xac/0x1c8) from [<c0334578>] > > (driver_probe_device+0x48/0x60) > > [<c0334578>] (driver_probe_device+0x48/0x60) from [<c03345f0>] > > (__driver_attach+0x60/0x84) > > [<c03345f0>] (__driver_attach+0x60/0x84) from [<c0332ce0>] > > (bus_for_each_dev+0x4c/0x80) > > [<c0332ce0>] (bus_for_each_dev+0x4c/0x80) from [<c0333414>] > > (bus_add_driver+0xa4/0x294) > > [<c0333414>] (bus_add_driver+0xa4/0x294) from [<c0334bdc>] > > (driver_register+0xa4/0x188) > > [<c0334bdc>] (driver_register+0xa4/0x188) from [<c0335c5c>] > > (platform_driver_probe+0x18/0x98) > > [<c0335c5c>] (platform_driver_probe+0x18/0x98) from [<c0008798>] > > (do_one_initcall+0xac/0x16c) > > [<c0008798>] (do_one_initcall+0xac/0x16c) from [<c06b52ac>] > > (do_basic_setup+0x88/0xc0) > > [<c06b52ac>] (do_basic_setup+0x88/0xc0) from [<c06b53c4>] > > (kernel_init+0x60/0xfc) > > [<c06b53c4>] (kernel_init+0x60/0xfc) from [<c00150a4>] > > (kernel_thread_exit+0x0/0x8) > > ---[ end trace 1b75b31a2719ed1c ]--- > > -----------------------------cut------------------------------- > > > > After that, the board continues to function properly. > > Any hints how to debug this? > > Probably the core problem is that we don't yet have the IPSS correctly > supported in the AM35xx hwmod data. This is partially due to the fact > that we're missing hierarchical enables/disables in that code, a > longstanding omission. My guess is that if you hacked in some code to > enable the IPSS early in boot (see the CONTROL_IPSS_CLK_CTRL register), > the problem would probably go away. > I suspect, the module MPU is trying to access is still not out of reset which is leading to the error. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
