[U-Boot] Driver-model - Issue with early device_probe
Suneel Garapati
suneelglinux at gmail.com
Fri Feb 24 18:39:25 UTC 2017
On Tue, Feb 21, 2017 at 7:59 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Suneel,
>
> On 17 February 2017 at 17:44, Suneel Garapati <suneelglinux at 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
More information about the U-Boot
mailing list