Hi Stephen,
On Jan 18, 2016 10:26, "Stephen Warren" swarren@wwwdotorg.org wrote:
On 01/17/2016 08:58 PM, Simon Glass wrote:
Hi Stephen,
On 15 January 2016 at 16:53, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/13/2015 08:46 PM, Simon Glass wrote:
Applied to u-boot-dm/next.
This change has removed/disabled/... PCIe support on at least Jetson TK1. I haven't checked the other Tegra boards.
My local copy works OK.
What did you test? My test was to look at the U-Boot boot logs and verify that the RTL8169#0 device was probed, and that "dhcp zImage" worked as expected once the prompt appeared.
I suspect something else (perhaps a later or earlier change) has broken this.
This change is definitely the cause. If I check out this change, the NIC doesn't work. If I check out the previous change, the NIC does work. If I check out u-boot/master, the NIC does not work. If I then revert this change, the NIC does work.
I mean the patch series that I sent at the time. I suppose PCI probing has changed since then. Possibly I made the change, not sure.
The problem is that PCI is no-longer probed on start-up. With driver model I'm trying to make things start when needed. It doesn't work with networking as it is currently implemented.
Isn't that going to be a regression; users will have to type extra commands to get PCIe NICs working if they don't automatically probe, won't they? I don't think that having PCI probed when it's first used is a good solution, since that means that any environment variables that are set during probing (such as ethact, ethaddr) won't be set, which will be a regression for any scripts that use them.
Something to think about. For now I sent a patch which probes PCI in the Ethernet uclass.
I'll send some patches to probe PCI from the network code, and tidy up a few things. My jetson-tk1 is a bit broken (the PMIC settings) but I've reproduced the problem on beaver.
Regards, Simon