[BUG] omap1 fails to boot on clock propagation

[BUG] omap1 fails to boot on clock propagation

[Łukasz Góralczyk]

Hello,

Some background:
Recently I've ported Linux to some custom omap1 based (5940 or 1510)
hardware. I've had some initial problems, but after a "dirty" fix I
have a running kernel and I can boot using NFS.

Problem:
On the very beginning kernel boot process stopped on clock propagation
routine (simple freeze, no crash info, nothing). After investigation I
have found that one memory read is at fault in function
omap1_ckctl_recalc_dsp_domain() in clock.c file:

dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));

My fix was to exchange read operation with default value of DSP_CKCTL register:

dsor = 1 << (3 & (0x009000090 >> clk->rate_offset));

Since this fix I haven't dug deeper into this problem, but it keeps me
thinking how to fix it properly. Any suggestions what might be the
root cause of this?

System info:
kernel version 3.5-rc1, kernel boots using some old Redboot
bootloader, compiled with gcc 4.6, almost bare metal kernel
configuration.

Thanks,
Lukasz G.

Re: [BUG] omap1 fails to boot on clock propagation

[Jon Hunter]

On 01/29/2013 03:53 AM, Łukasz Góralczyk wrote:
> Hello,
> 
> Some background:
> Recently I've ported Linux to some custom omap1 based (5940 or 1510)
> hardware. I've had some initial problems, but after a "dirty" fix I
> have a running kernel and I can boot using NFS.

Do you mean 5910? I am not familiar with a 5940.

> Problem:
> On the very beginning kernel boot process stopped on clock propagation
> routine (simple freeze, no crash info, nothing). After investigation I
> have found that one memory read is at fault in function
> omap1_ckctl_recalc_dsp_domain() in clock.c file:
> 
> dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
> 
> My fix was to exchange read operation with default value of DSP_CKCTL register:
> 
> dsor = 1 << (3 & (0x009000090 >> clk->rate_offset));
> 
> Since this fix I haven't dug deeper into this problem, but it keeps me
> thinking how to fix it properly. Any suggestions what might be the
> root cause of this?

Well looking at the code, in order to access the DSP_CKCTL register you
need to enable the api_ck first ...

omap1_clk_enable(api_ck_p);
dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
omap1_clk_disable(api_ck_p);

Therefore, I would check if the api_ck is actually being turned on, on
your platform. For example ...

omap1_clk_enable(api_ck_p);
pr_info("ARM_IDLECT2 = 0x%x\n", __raw_readw(ARM_IDLECT2));
omap1_clk_disable(api_ck_p);

Bit 6 in the ARM_IDLECT2 should be set if the api_ck is enabled.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] omap1 fails to boot on clock propagation

[Łukasz Góralczyk]

2013/1/29 Jon Hunter <jon-hunter@ti.com>
>
> On 01/29/2013 03:53 AM, Łukasz Góralczyk wrote:
> > Hello,
> >
> > Some background:
> > Recently I've ported Linux to some custom omap1 based (5940 or 1510)
> > hardware. I've had some initial problems, but after a "dirty" fix I
> > have a running kernel and I can boot using NFS.
>
> Do you mean 5910? I am not familiar with a 5940.

Yes, I hesitated for a moment if it was ...10 or ...40, it's *5910*.

> > Problem:
> > On the very beginning kernel boot process stopped on clock propagation
> > routine (simple freeze, no crash info, nothing). After investigation I
> > have found that one memory read is at fault in function
> > omap1_ckctl_recalc_dsp_domain() in clock.c file:
> >
> > dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
> >
> > My fix was to exchange read operation with default value of DSP_CKCTL register:
> >
> > dsor = 1 << (3 & (0x009000090 >> clk->rate_offset));
> >
> > Since this fix I haven't dug deeper into this problem, but it keeps me
> > thinking how to fix it properly. Any suggestions what might be the
> > root cause of this?
>
> Well looking at the code, in order to access the DSP_CKCTL register you
> need to enable the api_ck first ...
>
> omap1_clk_enable(api_ck_p);
> dsor = 1 << (3 & (__raw_readw(DSP_CKCTL) >> clk->rate_offset));
> omap1_clk_disable(api_ck_p);
>
> Therefore, I would check if the api_ck is actually being turned on, on
> your platform. For example ...
>
> omap1_clk_enable(api_ck_p);
> pr_info("ARM_IDLECT2 = 0x%x\n", __raw_readw(ARM_IDLECT2));
> omap1_clk_disable(api_ck_p);
>
> Bit 6 in the ARM_IDLECT2 should be set if the api_ck is enabled.

Thanks, now I'll know where to look.

Lukasz.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html