* Tero Kristo <t-kristo@xxxxxx> [140228 10:21]: > > Hmm, some clock node is broken, might be missing a name or parent > name for some reason. Can you try to boot with DEBUG enabled so you > get pr_debug:s out and see which clock is being initialized during > the crash? ... [ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: core_d18_ck [ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_mux_fck [ 0.000000] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_fck [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... We really should be registering the clocks lazily as needed BTW. That leaves out the dependency to DEBUG_LL for seeing any kind of decent error messages during the booting. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
