Re: AM3517 boot failure

[Tony Lindgren <tony@atomide.com>]

* 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