AM3517 boot failure

AM3517 boot failure

[Paul Walmsley]

Hi,

just wanted to mention this on the list to see if anyone else was seeing 
it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
boot hangs.  Here are the last few lines when booting with 
initcall_debug:

[    7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs
[    7.077880] calling  gpio_keys_init+0x0/0xc @ 1
[    7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs
[    7.091278] calling  rtc_hctosys+0x0/0x110 @ 1
[    7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs
[    7.111297] calling  net_secret_init+0x0/0x1c @ 1
[    7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs
[    7.123443] calling  tcp_congestion_default+0x0/0xc @ 1
[    7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs
[    7.136444] calling  ip_auto_config+0x0/0xf70 @ 1

Is anyone else seeing this?


- Paul

Re: AM3517 boot failure

[Igor Grinberg]

On 04/19/12 05:07, Paul Walmsley wrote:
> 
> Hi,
> 
> just wanted to mention this on the list to see if anyone else was seeing 
> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
> boot hangs.  Here are the last few lines when booting with 
> initcall_debug:
> 
> [    7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs
> [    7.077880] calling  gpio_keys_init+0x0/0xc @ 1
> [    7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs
> [    7.091278] calling  rtc_hctosys+0x0/0x110 @ 1
> [    7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> [    7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs
> [    7.111297] calling  net_secret_init+0x0/0x1c @ 1
> [    7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs
> [    7.123443] calling  tcp_congestion_default+0x0/0xc @ 1
> [    7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs
> [    7.136444] calling  ip_auto_config+0x0/0xf70 @ 1
> 
> Is anyone else seeing this?

I've tried various configurations and can confirm this hang.
I still haven't got my hands on bisecting this.
There is nothing special about CM-T3517,
IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported?

Thanks

-- 
Regards,
Igor.

Re: AM3517 boot failure

[Måns Rullgård]

Igor Grinberg <grinberg@compulab.co.il> writes:

> On 04/19/12 05:07, Paul Walmsley wrote:
>> 
>> Hi,
>> 
>> just wanted to mention this on the list to see if anyone else was seeing 
>> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
>> boot hangs.  Here are the last few lines when booting with 
>> initcall_debug:
>> 
>> [    7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs
>> [    7.077880] calling  gpio_keys_init+0x0/0xc @ 1
>> [    7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs
>> [    7.091278] calling  rtc_hctosys+0x0/0x110 @ 1
>> [    7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
>> [    7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs
>> [    7.111297] calling  net_secret_init+0x0/0x1c @ 1
>> [    7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs
>> [    7.123443] calling  tcp_congestion_default+0x0/0xc @ 1
>> [    7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs
>> [    7.136444] calling  ip_auto_config+0x0/0xf70 @ 1
>> 
>> Is anyone else seeing this?
>
> I've tried various configurations and can confirm this hang.
> I still haven't got my hands on bisecting this.
> There is nothing special about CM-T3517,
> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
> Anyway, can anybody try nfsroot on other AM35xx based board with EMAC
> supported?

I did a little digging...

Firstly, only the am3571evm board registers the davinci_emac platform
device.  On a Craneboard or a CM-T3517 there will simply be no network
device for IP autoconfig to use (unless you magically have DT working).

Secondly, the clock configuration for davinci_emac on am35xx is broken.
omap3xxx_clk_init() registers two clocks for dev_id "davinci_emac", one
with con_id "emac_clk", one with "phy_clk".  When davinci_emac_probe()
then does a clk_get(dev, NULL), this fails since there is no matching
con_id.  Likewise for davinci_mdio_probe().

With a little hacking, I got the platform device registered and the
clocks matching as (I think) they should.  It now detects the correct
PHY, so that's something.

However, the IP config is still getting stuck.  For reasons I don't
know, the msleep(1) call in ic_open_devs() never returns.

That's as far as I got.

-- 
Måns Rullgård
mans@mansr.com
--
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: AM3517 boot failure

[Tony Lindgren]

* Måns Rullgård <mans@mansr.com> [120419 08:31]:
> Igor Grinberg <grinberg@compulab.co.il> writes:
> 
> > On 04/19/12 05:07, Paul Walmsley wrote:
> >> 
> >> Hi,
> >> 
> >> just wanted to mention this on the list to see if anyone else was seeing 
> >> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
> >> boot hangs.  Here are the last few lines when booting with 
> >> initcall_debug:
> >> 
> >> [    7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs
> >> [    7.077880] calling  gpio_keys_init+0x0/0xc @ 1
> >> [    7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs
> >> [    7.091278] calling  rtc_hctosys+0x0/0x110 @ 1
> >> [    7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> >> [    7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs
> >> [    7.111297] calling  net_secret_init+0x0/0x1c @ 1
> >> [    7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs
> >> [    7.123443] calling  tcp_congestion_default+0x0/0xc @ 1
> >> [    7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs
> >> [    7.136444] calling  ip_auto_config+0x0/0xf70 @ 1
> >> 
> >> Is anyone else seeing this?
> >
> > I've tried various configurations and can confirm this hang.
> > I still haven't got my hands on bisecting this.
> > There is nothing special about CM-T3517,
> > IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
> > Anyway, can anybody try nfsroot on other AM35xx based board with EMAC
> > supported?
> 
> I did a little digging...
> 
> Firstly, only the am3571evm board registers the davinci_emac platform
> device.  On a Craneboard or a CM-T3517 there will simply be no network
> device for IP autoconfig to use (unless you magically have DT working).
> 
> Secondly, the clock configuration for davinci_emac on am35xx is broken.
> omap3xxx_clk_init() registers two clocks for dev_id "davinci_emac", one
> with con_id "emac_clk", one with "phy_clk".  When davinci_emac_probe()
> then does a clk_get(dev, NULL), this fails since there is no matching
> con_id.  Likewise for davinci_mdio_probe().
> 
> With a little hacking, I got the platform device registered and the
> clocks matching as (I think) they should.  It now detects the correct
> PHY, so that's something.
> 
> However, the IP config is still getting stuck.  For reasons I don't
> know, the msleep(1) call in ic_open_devs() never returns.
> 
> That's as far as I got.

Just to check, is this with the bad muxing removed in fixes branch? Without
that there can be all kinds of weird issues if some uart pins are used for
non-uart functionality:

bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads)?

Regards,

Tony


--
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: AM3517 boot failure

[Måns Rullgård]

Tony Lindgren <tony@atomide.com> writes:

> * Måns Rullgård <mans@mansr.com> [120419 08:31]:
>> Igor Grinberg <grinberg@compulab.co.il> writes:
>> 
>> > On 04/19/12 05:07, Paul Walmsley wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> just wanted to mention this on the list to see if anyone else was seeing 
>> >> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
>> >> boot hangs.  Here are the last few lines when booting with 
>> >> initcall_debug:
>> >> 
>> >> [    7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs
>> >> [    7.077880] calling  gpio_keys_init+0x0/0xc @ 1
>> >> [    7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs
>> >> [    7.091278] calling  rtc_hctosys+0x0/0x110 @ 1
>> >> [    7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
>> >> [    7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs
>> >> [    7.111297] calling  net_secret_init+0x0/0x1c @ 1
>> >> [    7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs
>> >> [    7.123443] calling  tcp_congestion_default+0x0/0xc @ 1
>> >> [    7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs
>> >> [    7.136444] calling  ip_auto_config+0x0/0xf70 @ 1
>> >> 
>> >> Is anyone else seeing this?
>> >
>> > I've tried various configurations and can confirm this hang.
>> > I still haven't got my hands on bisecting this.
>> > There is nothing special about CM-T3517,
>> > IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
>> > Anyway, can anybody try nfsroot on other AM35xx based board with EMAC
>> > supported?
>> 
>> I did a little digging...
>> 
>> Firstly, only the am3571evm board registers the davinci_emac platform
>> device.  On a Craneboard or a CM-T3517 there will simply be no network
>> device for IP autoconfig to use (unless you magically have DT working).
>> 
>> Secondly, the clock configuration for davinci_emac on am35xx is broken.
>> omap3xxx_clk_init() registers two clocks for dev_id "davinci_emac", one
>> with con_id "emac_clk", one with "phy_clk".  When davinci_emac_probe()
>> then does a clk_get(dev, NULL), this fails since there is no matching
>> con_id.  Likewise for davinci_mdio_probe().

This clock problem was recently fixed in the linux-omap tree.  I should
have made sure my tree was fully up to date before poking around.

>> With a little hacking, I got the platform device registered and the
>> clocks matching as (I think) they should.  It now detects the correct
>> PHY, so that's something.
>> 
>> However, the IP config is still getting stuck.  For reasons I don't
>> know, the msleep(1) call in ic_open_devs() never returns.
>> 
>> That's as far as I got.
>
> Just to check, is this with the bad muxing removed in fixes branch? Without
> that there can be all kinds of weird issues if some uart pins are used for
> non-uart functionality:
>
> bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads)?

Same problem on linux-omap master.

If I simply drop the msleep() calls (and use CONFIG_PREEMPT), it
progresses a bit further.  With a static IP config provided,
ip_auto_config() returns and it hangs somewhere else.  With ip=dhcp it
sends out a DHCP request but gets stuck waiting for the reply.

-- 
Måns Rullgård
mans@mansr.com
--
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: AM3517 boot failure

[Mark A. Greer]

On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote:
> Igor Grinberg <grinberg@compulab.co.il> writes:
> 
> > On 04/19/12 05:07, Paul Walmsley wrote:
> >> 
> >> Hi,
> >> 
> >> just wanted to mention this on the list to see if anyone else was seeing 
> >> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
> >> boot hangs.  Here are the last few lines when booting with 
> >> initcall_debug:

> I did a little digging...

> Secondly, the clock configuration for davinci_emac on am35xx is broken.
> omap3xxx_clk_init() registers two clocks for dev_id "davinci_emac", one
> with con_id "emac_clk", one with "phy_clk".  When davinci_emac_probe()
> then does a clk_get(dev, NULL), this fails since there is no matching
> con_id.  Likewise for davinci_mdio_probe().

This is fixed by 59269b94483eabeacbc9a535944b3dafac92a303
(ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases) from
Ilya Yanok <yanok@emcraft.com>.  Its in the current mainline kernel.

I'm sure you already know this but I want to make everyone is aware--don't
forget to enable davinci_emac because it isn't in omap2plus_defconfig.
Matt Porter <mporter@ti.com> submitted a patch for that some time ago
but I don't know its status:

	http://www.spinics.net/lists/linux-omap/msg64367.html

> With a little hacking, I got the platform device registered and the
> clocks matching as (I think) they should.  It now detects the correct
> PHY, so that's something.
> 
> However, the IP config is still getting stuck.  For reasons I don't
> know, the msleep(1) call in ic_open_devs() never returns.
> 
> That's as far as I got.

I tried the current mainline on my am3517 evm and it hangs as well.
I'm not surprised, the am35xx has some serious issues ATM.  I submitted
a set of patches to fix a lot of them but they need to be reworked.
I'm working on that now.

Until then, don't expect much to work well.  If it does seem to work well,
you got lucky.  If you want to get running quickly, try the ***HACK***
below.  Current mainline boot with it applied, CONFIG_TI_DAVINCI_EMAC=y,
boots on my am3517 evm with both an MMC-mounted & NFS-mounted rootfs.

Mark
--

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..187f5cb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -705,7 +705,6 @@ static int __init omap3_pm_init(void)
        struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
        int ret;
 
-       if (!cpu_is_omap34xx())
                return -ENODEV;
 
        if (!omap3_has_io_chain_ctrl())
--
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: AM3517 boot failure

[Måns Rullgård]

"Mark A. Greer" <mgreer@animalcreek.com> writes:

> On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote:
>> Igor Grinberg <grinberg@compulab.co.il> writes:
>> 
>> > On 04/19/12 05:07, Paul Walmsley wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> just wanted to mention this on the list to see if anyone else was seeing 
>> >> it.  I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the 
>> >> boot hangs.  Here are the last few lines when booting with 
>> >> initcall_debug:
>
>> I did a little digging...
>
>> Secondly, the clock configuration for davinci_emac on am35xx is broken.
>> omap3xxx_clk_init() registers two clocks for dev_id "davinci_emac", one
>> with con_id "emac_clk", one with "phy_clk".  When davinci_emac_probe()
>> then does a clk_get(dev, NULL), this fails since there is no matching
>> con_id.  Likewise for davinci_mdio_probe().
>
> This is fixed by 59269b94483eabeacbc9a535944b3dafac92a303
> (ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases) from
> Ilya Yanok <yanok@emcraft.com>.  Its in the current mainline kernel.

Yeah, I noticed after I'd already figured out why it was failing.  Oh
well, it was a good exercise.

>> With a little hacking, I got the platform device registered and the
>> clocks matching as (I think) they should.  It now detects the correct
>> PHY, so that's something.
>> 
>> However, the IP config is still getting stuck.  For reasons I don't
>> know, the msleep(1) call in ic_open_devs() never returns.
>> 
>> That's as far as I got.
>
> I tried the current mainline on my am3517 evm and it hangs as well.
> I'm not surprised, the am35xx has some serious issues ATM.  I submitted
> a set of patches to fix a lot of them but they need to be reworked.
> I'm working on that now.
>
> Until then, don't expect much to work well.  If it does seem to work well,
> you got lucky.  If you want to get running quickly, try the ***HACK***
> below.  Current mainline boot with it applied, CONFIG_TI_DAVINCI_EMAC=y,
> boots on my am3517 evm with both an MMC-mounted & NFS-mounted rootfs.
>
> Mark
> --
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 703bd10..187f5cb 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -705,7 +705,6 @@ static int __init omap3_pm_init(void)
>         struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
>         int ret;
>
> -       if (!cpu_is_omap34xx())
>                 return -ENODEV;
>
>         if (!omap3_has_io_chain_ctrl())

That does indeed make it boot.

-- 
Måns Rullgård
mans@mansr.com
--
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: AM3517 boot failure

[Jan Lübbe]

On Thu, 2012-04-19 at 10:57 +0300, Igor Grinberg wrote: 
> On 04/19/12 05:07, Paul Walmsley wrote:
> > Is anyone else seeing this?
> 
> I've tried various configurations and can confirm this hang.
> I still haven't got my hands on bisecting this.
> There is nothing special about CM-T3517,
> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
> Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported?

I have a board with the AM3505 and NFS root works fine here. I'm using
3.4-rc3, Mark A. Greer's patch series on this list (2012-04-11) and Paul
Walmsley's fixes-for-v3.4-rc3 tag. A possible difference is that I'm
using the fixed PHY driver.

Best regards,
Jan Lübbe
--
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: AM3517 boot failure

[Paul Walmsley]

On Thu, 19 Apr 2012, Igor Grinberg wrote:

> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?

Just tested this on a 3517EVM and the same problem is there too.


- Paul

Re: AM3517 boot failure

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> On Thu, 19 Apr 2012, Igor Grinberg wrote:
>
>> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
>
> Just tested this on a 3517EVM and the same problem is there too.

Does adding nohlt on the cmdline make a difference?

The AM35x has known wakeup limitations, and nohlt would at least avoid
WFI to see if it's the wakeup problems that are the root cause here.

Kevin

Re: AM3517 boot failure

[Paul Walmsley]

Hi Kevin,

thanks for the suggestion,

On Tue, 8 May 2012, Kevin Hilman wrote:

> Paul Walmsley <paul@pwsan.com> writes:
> 
> > On Thu, 19 Apr 2012, Igor Grinberg wrote:
> >
> >> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
> >
> > Just tested this on a 3517EVM and the same problem is there too.
> 
> Does adding nohlt on the cmdline make a difference?
> 
> The AM35x has known wakeup limitations, and nohlt would at least avoid
> WFI to see if it's the wakeup problems that are the root cause here.

Adding 'nohlt' allows it to go a little farther in the boot, but still 
hangs.  Log below.

(Without 'nohlt', it hangs right after "calling  ip_auto_config+0x0/0xf70 
@ 1")


- Paul

[    6.250946] calling  net_secret_init+0x0/0x1c @ 1
[    6.255981] initcall net_secret_init+0x0/0x1c returned 0 after 119 
usecs
[    6.263092] calling  tcp_congestion_default+0x0/0xc @ 1
[    6.268646] initcall tcp_congestion_default+0x0/0xc returned 0 after 29 
usecs
[    6.276184] calling  ip_auto_config+0x0/0xf70 @ 1
[    6.325500] mmc0: new high speed SDHC card at address b368
[    6.334686] mmcblk0: mmc0:b368 USD   3.75 GiB 
[    6.347686]  mmcblk0: p1 p2 p3
[   18.374359] initcall ip_auto_config+0x0/0xf70 returned -19 after 
11809741 use
cs
[   18.382141] calling  initialize_hashrnd+0x0/0x1c @ 1
[   18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59 
usecs
[   18.397949] async_waiting @ 1
[   18.401184] async_continuing @ 1 after 119 usec
(hangs)

Re: AM3517 boot failure

[Måns Rullgård]

Paul Walmsley <paul@pwsan.com> writes:

> Hi Kevin,
>
> thanks for the suggestion,
>
> On Tue, 8 May 2012, Kevin Hilman wrote:
>
>> Paul Walmsley <paul@pwsan.com> writes:
>> 
>> > On Thu, 19 Apr 2012, Igor Grinberg wrote:
>> >
>> >> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
>> >
>> > Just tested this on a 3517EVM and the same problem is there too.
>> 
>> Does adding nohlt on the cmdline make a difference?
>> 
>> The AM35x has known wakeup limitations, and nohlt would at least avoid
>> WFI to see if it's the wakeup problems that are the root cause here.
>
> Adding 'nohlt' allows it to go a little farther in the boot, but still 
> hangs.  Log below.
>
> (Without 'nohlt', it hangs right after "calling  ip_auto_config+0x0/0xf70 
> @ 1")
>
> - Paul
>
> [    6.250946] calling  net_secret_init+0x0/0x1c @ 1
> [    6.255981] initcall net_secret_init+0x0/0x1c returned 0 after 119 
> usecs
> [    6.263092] calling  tcp_congestion_default+0x0/0xc @ 1
> [    6.268646] initcall tcp_congestion_default+0x0/0xc returned 0 after 29 
> usecs
> [    6.276184] calling  ip_auto_config+0x0/0xf70 @ 1
> [    6.325500] mmc0: new high speed SDHC card at address b368
> [    6.334686] mmcblk0: mmc0:b368 USD   3.75 GiB 
> [    6.347686]  mmcblk0: p1 p2 p3
> [   18.374359] initcall ip_auto_config+0x0/0xf70 returned -19 after 
> 11809741 use
> cs
> [   18.382141] calling  initialize_hashrnd+0x0/0x1c @ 1
> [   18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59 
> usecs
> [   18.397949] async_waiting @ 1
> [   18.401184] async_continuing @ 1 after 119 usec
> (hangs)

Are you still trying nfsroot?  Since ip_auto_config failed, it will have
no way of mounting the nfsroot and stop there.  Do you know why ip setup
failed?

-- 
Måns Rullgård
mans@mansr.com
--
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: AM3517 boot failure

[Mark A. Greer]

On Tue, May 08, 2012 at 09:49:26AM -0600, Paul Walmsley wrote:
> Hi Kevin,
> 
> thanks for the suggestion,
> 
> On Tue, 8 May 2012, Kevin Hilman wrote:
> 
> > Paul Walmsley <paul@pwsan.com> writes:
> > 
> > > On Thu, 19 Apr 2012, Igor Grinberg wrote:
> > >
> > >> IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
> > >
> > > Just tested this on a 3517EVM and the same problem is there too.
> > 
> > Does adding nohlt on the cmdline make a difference?
> > 
> > The AM35x has known wakeup limitations, and nohlt would at least avoid
> > WFI to see if it's the wakeup problems that are the root cause here.
> 
> Adding 'nohlt' allows it to go a little farther in the boot, but still 
> hangs.  Log below.
> 
> (Without 'nohlt', it hangs right after "calling  ip_auto_config+0x0/0xf70 
> @ 1")

Just to make sure, you do have CONFIG_TI_DAVINCI_EMAC enabled, right?
Its not enabled in omap2plus_defconfig.

Mark