* Pandita, Vikram <vikram.pandita@xxxxxx> [100210 14:56]: <snip> > >> > The kernel panics during I2C init in function omap3_evm_i2c_init() > >> > during this call: > >> > > >> > omap_register_i2c_bus(2, 400, NULL, 0); > > I see that Zoom2/3 also don't boot up and given that DEBUG_LL does not work for these boards, > its very difficult to narrow down the problem. > > After around 2 hours of narrowing down, this is what solves the issue probably: > m0_entry seems to be null, causing strcmp() to crash. > > Patch: (will not apply as TABS are not there :) ) > diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c > index 986077f..d5a03f8 100644 > --- a/arch/arm/mach-omap2/mux.c > +++ b/arch/arm/mach-omap2/mux.c > @@ -435,7 +435,7 @@ int __init omap_mux_init_signal(char *muxname, int val) > char *m0_entry = m->muxnames[0]; > int i; > > - if (m0_name && strcmp(m0_name, m0_entry)) > + if (m0_name && m0_entry && strcmp(m0_name, m0_entry)) > continue; > > for (i = 0; i < OMAP_MUX_NR_MODES; i++) { > > Hmm is this only with CONFIG_OMAP_MUX and only on 3630? In for-next we don't have yet the recent mux fix commit 9ecef433204f9b06550dd45cf84f14706f8fe4f0. Can you make sure you have that applied and see if that solves the problem? To me it seems that m0_entry should never be NULL after mux init as that's the signal register name. The 3630 entries should get populated by omap_mux_init_list. If omap36xx_cbp_subset is missing some of the 3630 only entries added by commit 9ecef433204f9b06550dd45cf84f14706f8fe4f0 into omap3_muxmodes, then that would explain why m0_entry would be NULL.. Anyways, as I don't have a 3630 here I'm just guessing. Until you get the DEBUG_LL working on zoom3, you can just increase the CONFIG_LOG_BUF_SHIFT to something large enough and printk m0_name and m0_entry without doing anything with them. Then after the boot you can take a look at dmesg and see if it provides any clues. Regards, Tony -- 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