Re: AM3517 boot failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


[Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux