On Tue, Feb 21, 2017 at 7:59 PM, Simon Glass <s...@chromium.org> wrote: > Hi Suneel, > > On 17 February 2017 at 17:44, Suneel Garapati <suneelgli...@gmail.com> wrote: >> Hi All, >> Request for help on the below issue. >> >> Hi Simon, >> As I suppose it is related to driver-model in u-boot. >> >> One of the boards at Cavium has SPI as PCI device and I am trying to >> enable CONFIG_ENV_IS_IN_SPI_FLASH for this device. >> >> Below is the sequence which causes crash, due to early of probing for >> all parent and children in PCI node of devicetree. As some drivers, >> like network, have to have eth_initialize called before to have global >> structures initialized. >> >> 1. Init_sequence_r in board_r.c calls initr_env before any other >> framework init is called. >> 2. initr_env checks for the device to load environment from, SPI, >> calls env_relocate_spec from env_sf.c >> 3. SPI probe is triggered from env_relocate_spec, because of driver >> model framework, this internally triggers device_probe. >> 4. device_probe iterates on spi parent, PCI, and its childs and calls >> probe on each of them. >> 5. This early probe call may work for some frameowrks but not for all. >> 6. Network drivers like thunderx_smi (pci device) probe calls >> mdio_register, internally calls miiphy_get_dev_by_name which tries to >> access list mii_devs, which is uninitialized at this moment and >> crashes. >> 7. mii_devs is initialized through mii_phy_init, called from >> initr_net->eth_initialize->eth_common_init. >> 8. initr_net is called much later in init_sequence_r. >> >> There is no CONFIG item to have control on environment storage devices >> like MMC,SPI,NOR flash device probes to be singled out in the >> initr_env initcall. >> >> Please suggest on how to fix it or workaround. Also, let me know if I >> am missing something obvious here. > > I think the root cause is that Ethernet PHYs do not yet use driver > model. If that were fixed, then things should work fine. > > eth_common_init() is a work-around which should go away once we have > this support. > > For now, you could call eth_common_init() from your board code (e.g. > in board_early_init_r()) perhaps? You may need to find a way to > disable the later call, but perhaps it will not matter?
Thanks Simon, Workaround - Using board_early_init_r to call eth_common_init() helps. It matters if we dont disable the later call, eth_devices will re-initialize to NULL and miiphy_init will make it lose all mdio inited devices. Regards, Suneel > > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
