Looks suspiciously like the symptons in
http://code.google.com/p/beagleboard/issues/detail?id=14
regards,
Koen
* Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
>
> Hello everyone,
>
> occasionally the TWL4030 driver on the 3430SDP freaks out on boot.
> (This
> is either an ES2.0 or ES2.1, not sure.) Here's a partial console
> log with
> initcall debugging enabled. This probably happens every thirty or
> forty
> boots, I would guess. The board does boot to userspace when this
> happens.
>
> Perhaps the TWL4030 experts out there might know what's going on?
>
> <3>i2c_omap i2c_omap.1: controller timed out
> <3>i2c_omap i2c_omap.1: controller timed out
> <3>twl4030_usb: i2c write failed, line 422Looks suspiciously like the symptons in
Google Code Archive - Long-term storage for Google Code Project Hosting.
This also looks similar to the earlier twl4030 hangs where access
to some domains caused twl4030 to hang. If twl4030 hangs, there's
no way to reset it as all control is over I2C. When twl4030 hangs,
bootloader won't be able to detect the chip either unless devices
is power cycled (and USB cable detached).
The reason earlier was that twl4030 internal clock was not being
programmed properly, and was fixed by patch
0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
Maybe there's some twl4030 register access going on before the
internal clock is programmed properly?
Tony
IRQ 56 is the TWL4030 I2C1 IRQ. Seems strange that there would be no
handler for it after i2c_omap has initialized...
- Paul
Tony Lindgren wrote:
* Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
Hello everyone,
occasionally the TWL4030 driver on the 3430SDP freaks out on boot. (This
is either an ES2.0 or ES2.1, not sure.) Here's a partial console log with
initcall debugging enabled. This probably happens every thirty or forty
boots, I would guess. The board does boot to userspace when this happens.Perhaps the TWL4030 experts out there might know what's going on?
<3>i2c_omap i2c_omap.1: controller timed out
<3>twl4030_usb: i2c write failed, line 422Looks suspiciously like the symptons in
Google Code Archive - Long-term storage for Google Code Project Hosting.
This also looks similar to the earlier twl4030 hangs where access
to some domains caused twl4030 to hang. If twl4030 hangs, there's
no way to reset it as all control is over I2C. When twl4030 hangs,
bootloader won't be able to detect the chip either unless devices
is power cycled (and USB cable detached).The reason earlier was that twl4030 internal clock was not being
programmed properly, and was fixed by patch
0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.
Link for this is
I don't know OMAP3 good enough yet, but which clock should we use on OMAP3 here?
Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
E.g something like
...
if (cpu_is_omap2430() || cpu_is_omap34xx())
osc = clk_get(NULL, "osc_ck");
else
osc = clk_get(NULL, "osc_sys_ck");
...
Dirk
* Dirk Behme <dirk.behme@googlemail.com> [080509 11:08]:
Tony Lindgren wrote:
* Koen Kooi <k.kooi@student.utwente.nl> [080508 11:22]:
Hello everyone,
occasionally the TWL4030 driver on the 3430SDP freaks out on boot.
(This
is either an ES2.0 or ES2.1, not sure.) Here's a partial console
log with
initcall debugging enabled. This probably happens every thirty or
forty
boots, I would guess. The board does boot to userspace when this
happens.Perhaps the TWL4030 experts out there might know what's going on?
<3>i2c_omap i2c_omap.1: controller timed out
<3>i2c_omap i2c_omap.1: controller timed out
<3>twl4030_usb: i2c write failed, line 422Looks suspiciously like the symptons in
Google Code Archive - Long-term storage for Google Code Project Hosting.
This also looks similar to the earlier twl4030 hangs where access
to some domains caused twl4030 to hang. If twl4030 hangs, there's
no way to reset it as all control is over I2C. When twl4030 hangs,
bootloader won't be able to detect the chip either unless devices
is power cycled (and USB cable detached).The reason earlier was that twl4030 internal clock was not being
programmed properly, and was fixed by patch
0d81cf7e804c529c58d3054c1b9bdb7b3f1dec5d.Link for this is
I don't know OMAP3 good enough yet, but which clock should we use on
OMAP3 here?
It should be osc_sys_ck for 34xx.
Does it make sense to use osc_ck for OMAP3 instead of osc_sys_ck, too?
E.g something like
...
if (cpu_is_omap2430() || cpu_is_omap34xx())
osc = clk_get(NULL, "osc_ck");
else
osc = clk_get(NULL, "osc_sys_ck");
...
There's no osc_ck in clock34xx.h.
But what I'm thinking is that maybe the MMC driver does twl4030 calls
before the twl4030 clock is programmed to the right value?
Tony
FWIW, I've never had any issues with the twl4030 on my OMAP3 EVM.
Both it and the MMC come up fine every boot.
I'm sure that by saying that I have jinxed myself and will have no end
of issues from this point forward 
It's not obvious from looking at the board files why this might be.
Perhaps the order of inits?
Steve
Steve Sakoman wrote:
FWIW, I've never had any issues with the twl4030 on my OMAP3 EVM.
Both it and the MMC come up fine every boot.I'm sure that by saying that I have jinxed myself and will have no end
of issues from this point forwardIt's not obvious from looking at the board files why this might be.
Perhaps the order of inits?
How do you boot OMAP3 EVM? Or better, does your bootloader touch TWL?
Below, Tony mentioned "But what I'm thinking is that maybe the MMC driver does twl4030 calls before the twl4030 clock is programmed to the right value?"
Looking into U-Boot for Beagle in u-boot/cpu/omap3/mmc.c there is
void twl4030_mmc_config(void)
{
unsigned char data;
data = 0x20;
i2c_write(0x4B, 0x82, 1, &data, 1);
data = 0x2;
i2c_write(0x4B, 0x85, 1, &data, 1);
return 1;
}
So, on Beagle we are touching TWL *before* kernel (can program right clock value). Now, I wonder if u-boot code above is correct compared to kernel/drivers/i2c/chips/twl4030-core.c :
static int power_companion_init(void)
{
struct clk *osc;
u32 rate;
u8 ctrl = HFCLK_FREQ_26_MHZ;
int e = 0;
if (cpu_is_omap2430())
osc = clk_get(NULL, "osc_ck");
else
osc = clk_get(NULL, "osc_sys_ck");
if (IS_ERR(osc)) {
printk(KERN_WARNING "Skipping twl3040 internal clock init and "
"using bootloader value (unknown osc rate)\n");
return 0;
}
rate = clk_get_rate(osc);
clk_put(osc);
switch (rate) {
case 19200000 : ctrl = HFCLK_FREQ_19p2_MHZ; break;
case 26000000 : ctrl = HFCLK_FREQ_26_MHZ; break;
case 38400000 : ctrl = HFCLK_FREQ_38p4_MHZ; break;
}
ctrl |= HIGH_PERF_SQ;
e |= unprotect_pm_master();
/* effect->MADC+USB ck en */
e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl, R_CFG_BOOT);
e |= protect_pm_master();
return e;
}
or if we have to add/remove/fix something in U-Boot?
Dirk
A grep of u-boot sources for the OMAP3 EVM does not yield any
occurrences of twl403 so you might be on to something with this
theory!
Also, I boot from on-board onenand so that is another major difference.
Steve
Hi,
A grep of u-boot sources for the OMAP3 EVM does not yield any
occurrences of twl403 so you might be on to something with this
theory!
Your SYS_BOOT line values make a difference in TWL behavior. The mask ROM knows specifics about this companion chip.
One aspect people seem to miss is the fact that the mask ROM will touch T2 based on the boot order. The mask ROM also monkeys with some internal clocks and modules.
So, just because your x-loader or u-boot doesn't touch a register that doesn't mean the mask ROM hasn't. So don't expect reset value.
Regards,
Richard W.
Op 10 mei 2008, om 16:57 heeft Woodruff, Richard het volgende
geschreven:
Hi,
A grep of u-boot sources for the OMAP3 EVM does not yield any
occurrences of twl403 so you might be on to something with this
theory!Your SYS_BOOT line values make a difference in TWL behavior. The
mask ROM knows specifics about this companion chip.One aspect people seem to miss is the fact that the mask ROM will
touch T2 based on the boot order. The mask ROM also monkeys with
some internal clocks and modules.So, just because your x-loader or u-boot doesn't touch a register
that doesn't mean the mask ROM hasn't. So don't expect reset value.
Would it be an option to dump TWL regs with something like devmem2
after boot for the .22 WTBU kernels and linux-omap git ones? Or just
printk() them during early boot? It would be nice the have the correct
values, so the git twl driver can use those.
regards,
Koen