[U-Boot] [PATCH v3 25/35] dm: tegra: pci: Convert to livetree

[Simon Glass]

Hi Stephen,

On 7 July 2017 at 09:50, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/06/2017 09:57 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 6 July 2017 at 12:55, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>>
>>> On 07/06/2017 11:36 AM, sjg at google.com wrote:
>>>>
>>>>
>>>> Update the tegra pci driver to support a live device tree. Fix the check
>>>> for nvidia,num-lanes so that an error will actually be detected.
>>>
>>>
>>>
>>> Simon,
>>>
>>> Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on
>>> Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test
>>> simply fails due to lack of any Ethernet adapter. I don't see any errors
>>> during either boot or the network test setup scripts, which include "pci
>>> enum":
>>>
>>> TK1 (built-in RTL8169 PCI Ethernet):
>>> Tegra124 (Jetson TK1) # ping $serverip
>>> No ethernet found.
>>> ping failed; host 192.168.100.1 is not alive
>>> Tegra124 (Jetson TK1) #
>>>
>>> TX1 (add-on RTL8169 PCI Ethernet):
>>> Tegra210 (P2371-2180) # pci enum
>>> ERROR: tegra-pcie: failed to power on PHY: -110
>>> at
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller()
>>> ERROR: tegra-pcie: failed to enable controller
>>> at
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe()
>>> Tegra210 (P2371-2180) # setenv autoload no
>>> Tegra210 (P2371-2180) # dhcp
>>> No ethernet found.
>>> Tegra210 (P2371-2180) #
>>>
>>> I also retested u-boot/master to make sure there's no test system
>>> infrastructure issue (that branch passes), and re-ran the failing test 3
>>> times on TK1 with identical results. Other Tegra boards that I test all seem
>>> fine, at least as far as passing test/py.
>>>
>>> P.S. I'll be away next week and the week after. Tom Warren may be able to
>>> monitor the test system emails, but I don't think I've set him up with
>>> access to e.g. retrigger tests etc.; perhaps I should look into that...
>>
>>
>> As mentioned elsewhere that error (failing to power on PHY) happens
>> for me always on my TK1 (and has for about a year) because it seems to
>> have a broken PMIC. I do have a TX1 somewhere but cannot find it
>> despite much searching.
>
>
> I'm very puzzled that you claim your TK1 always has this issue; this issue
> is clearly not present in mainline U-Boot (unless it's very intermittent and
> my test system has got lucky, but it's very reproducible so I don't think
> so), and I don't believe there's anything in the the PMIC that can be
> altered permanently; the boot configuration is in OTP (One Time
> Programmable) memory (fuses?) and can't be changed. Are you absolutely 100%
> sure that you cleanly replaced your development version of U-Boot correctly
> and tested with a 100% unmodified mainline U-Boot? Also, please try (a)
> flashing unmodified mainline U-Boot (b) disconnecting EVERY cable from the
> TK1 and leaving it that way for 10 minutes to drain any capacitors (or
> perhaps even overnight) (c) powering up to see if any problems still exist.

I have tried to explain this quite a few times.

My TK1 has some sort of power problem. I think it is due to my
overwriting the PMIC registers with invalid values during some I2C
testing a while back.

I'll try what you suggest, although I do generally leave it powered
off between use.

>
>> Obviously I chose Tegra for the livetree work based on Nyan which I
>> have and which is quick to develop on. I am beginning to regret this
>> because:
>>
>> - No one at Nvidia appears to be maintaining the code at present -
>> e.g. DM enablement, Kconfig versions
>
>
> Well, the existing code works perfectly. There's no need to change it. If
> you want to change it, that's fine, but you must take on the job of
> validating your changes and fixing any issues they introduce. It's not
> reasonable to introduce changes that break things and then try and push
> forward with them even in the face of known breakage caused by those
> changes. It's not reasonable to create patches that introduce problems and
> then expect others to do the work of debugging and fixing them.

That's a different point. Please see the point I made above. Kconfig
conversion needs to be completed by the end of this year [1] and DM
conversion needs to be done at some point (no specific deadline).

>
>> - The test report you provides is a signal, but it is not actionable for
>> me
>
>
> Why is it not actionable? You possess hardware that will reproduce the
> change (your TX1 board even if not the TK1 system). The test system source
> is checked into the U-Boot source tree and available to you, although I
> believe that simply running "pci enum; dhcp Image" should reproduce the
> problem so it's even simpler than running test/py.

I have this morning found the TX1 board so hopefully can figure this out!

>
>> - As above due to broken/lost boards I am not able to test as well as
>> I originally thought
>
>
> Perhaps you should only modify the boards you can test? You mentioned that
> Nyan works for you. If so, limit the modifications to the
> boards/drivers/features you have available.

Yes that was my original series, but Nyan does not have PCI.

>
>> Is there any way someone at Nvidia could jump into this and work on
>> bringing mainline up to scratch?
>
>
> If anyone can, it'd be Tom Warren.
>
> P.S. I'm on vacation for the next 2 weeks, so won't be able to respond
> further for a while.

Have a nice break.

Regards,
Simon

[1] https://lists.denx.de/pipermail/u-boot/2017-January/277605.html