U-Boot Driver for Ethernet Controller

What means “Note that by default the PCIe port is also left disabled in the device tree which needs changing as well for this to actually work.” in the description for APALIS_TK1_PCIE_EVALBOARD_INIT? Has there to be done something in addition?

Not unless you do require the PCIe switch on the Apalis Evaluation board to also be initialised in U-Boot upon explicitly doing pci enum. As mentioned before regular booting does not need any such. Also just gigabit Ethernet does not need this as that one is always initialised by default upon explicitly doing pci enum.

Not unless you do require the PCIe switch on the Apalis Evaluation board to also be initialised in U-Boot upon explicitly doing pci enum.

Ok, we do not need the PCIe swtich on the Apalis board. (We would just need that in case we would debug with the Apalis Evaluation board again I guess.)

In case we do not want to build an debug u-boot version for the Apalis Eval board: Would enabling APALIS_TK1_PCIE_EVALBOARD_INIT do any harm if the TK1 is not assembled in an Apalis Evaluation board but a production board?

As mentioned before regular booting does not need any such.

Ok, then our optional firmware update after the poweron of the TK1 (which depends on pci enum in u-boot) will work without enabling APALIS_TK1_PCIE_EVALBOARD_INIT.

Also just gigabit Ethernet does not need this as that one is always initialised by default upon explicitly doing pci enum.

Ok, Gigabit ethernet is initialized independent of APALIS_TK1_PCIE_EVALBOARD_INIT.

Ok, we do not need the PCIe swtich on the Apalis board. (We would just need that in case we would debug with the Apalis Evaluation board again I guess.)

In case we do not want to build an debug u-boot version for the Apalis Eval board: Would enabling APALIS_TK1_PCIE_EVALBOARD_INIT do any harm if the TK1 is not assembled in an Apalis Evaluation board but a production board?

Not unless your production board does use Apalis GPIO 7 which is used as PEX_PERST_N aka the PCIe switch reset on the Apalis Evaluation board.

Ok, then our optional firmware update after the poweron of the TK1 (which depends on pci enum in u-boot) will work without enabling APALIS_TK1_PCIE_EVALBOARD_INIT.

Yes.

Ok, Gigabit ethernet is initialized independent of APALIS_TK1_PCIE_EVALBOARD_INIT.

Exactly.

What about #define RESET_MOCI_CTRL TEGRA_GPIO(U, 4) (which seems to be relevant in addition to #define PEX_PERST_N TEGRA_GPIO(DD, 1) /* Apalis GPIO7 */)?

What about #define RESET_MOCI_CTRL TEGRA_GPIO(U, 4) (which seems to be relevant in addition to #define PEX_PERST_N TEGRA_GPIO(DD, 1) /* Apalis GPIO7 */)?

I’m not sure what exactly you are trying to get at. It may control the RESET_MOCI_N signal which again is not boot relevant but of course may be relevant for optional things like mini-PCIe, PCIe or the USB hub for that matter.

I just want to make sure that the bugfix does not impact any functionality in case we run u-boot on the TK1 assembled onto our production board. You are right. That depends on our production board layout only.

Understood, no worries.

This fix has now been extensively tested in our temperature chamber over the full temperature range of -25 to 85 deg C. No further PCIe gigabit Ethernet issues have been observed.

Have you tested the u-boot patch and the linux patch together, right?

No, to be honest for now we just tested the U-Boot patch as that allowed easily quickly assessing whether or not technically that fix actually does what it is supposed to.

I’am just asking because I will then skip another u-boot patch only test run and run the test skript with both patches, the u-boot patch and the linux patch in the first place over night.

Sure, makes sense. We will do more Apalis TK1 validation & verification over time of course. But right now we just wanted to get some clarity hardware robustness wise as we already released V1.2A design data for production.

As part of our system level tests I ran the test script which executes cold-starts of the SOM over and over again with the Linux patch and the U-Boot patch built into our image and assembled into our device. The link is missing not that often any more but the “link miss ratio” is not significantly better than before (in 1 of approx. 40 cases compared to in 1 out of 30 cases I ran the test script). Have you ran tests with the kernel and the U-Boot patch built into your Linux image/BSP in the meanwhile which verifies how often the link is established? (I would like to make sure that our SW and/or HW does not impact the result in a negative way.)

Have you ran tests with the kernel and the U-Boot patch built into your Linux image/BSP in the meanwhile which verifies how often the link is established? (I would like to make sure that our SW and/or HW does not impact the result in a negative way.)

No, we plan to continue our validation & verification with the upcoming 2.7b4 Q3 release once the new V1.2A hardware revision becomes available.

Ok. thanks for the info. When will 2.7b4 Q3 be available?

At the beginning of Q4 aka early October.

Have there been changes between Apalis TK1 2GB V1.1A and V1.2A which could impact the reliability of the physical link establishment? (As we will use V1.2A at some point in time I would skip the tests of the physical link if there could be an impact.)

Some minor new errata(s) got integrated which may have some influence I guess. Unfortunately the PCN which will detail this is not quite ready yet. That said as mentioned before we are not aware of any existing such issues really.

Hi Marcel, I ran the test script (repeated cold-start + try to ping the SOM) with Apalis TK1 Linux BSP v2.7b3 non-mainline and our custom baseboard as carrier. It seems like the physical link establishment is quite stable. I would like to track down the possible root cause(s) for the physical link missing more often in our image and need some more information about the u-boot patch:

  • When is tegra_pcie_board_port_reset() and potentially other functionalities of the u-boot patch to fix “pci devices not listed” executed? Is it only executed when the u-boot command pci enum (e.g. as part of a TFTP update setup) or some other ethernet functionality is used? Or are patch functionalities executed in every case even if the ethernet is not used in u-boot at all?
  • When is tegra_pcie_board_port_reset() and potentially other functionalities of the u-boot patch to fix “missing physical link” executed? (same as above)