Re: omap3evm: Doesn't boot at 4fa42e46

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux