Tony Lindgren <tony@xxxxxxxxxxx> writes: > * Måns Rullgård <mans@xxxxxxxxx> [120419 08:31]: >> Igor Grinberg <grinberg@xxxxxxxxxxxxxx> 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@xxxxxxxxx -- 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
