U-Boot Driver for Ethernet Controller

That means if I depend on pci enum in u-boot for an optional firmware update after the poweron of the TK1 I should enable the option CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT=y in e.g. /configs/apalis-tk1_defconfig to enable it during the build of u-boot where make apalis-tk1_defconfig is invoked, right? (Actually not apalis-tk1_defconfig but a file which is based on apalis-tk1_defconfig.)

I merged the patch into our u-boot. However the build of u-boot fails with

board/toradex/apalis-tk1/apalis-tk1.c:13:23: fatal error: pci_tegra.h: No such file or directory
compilation terminated.
make[1]: *** [board/toradex/apalis-tk1/apalis-tk1.o] Error 1

because the file #include <pci_tegra.h> seems to be missing.

EDIT:

I missed to merge the other commits before as well…

Please note the fix is not just a single commit but rather a series of dependent ones.

I applied patch “pci: tegra: introduce weak tegra_pcie_board_port_reset() function”, patch “apalis-tk1: fix pcie reset for reliable gigabit ethernet operation” and enabled CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT=y in /configs/apalis-tk1_defconfig. The link is still not established sometimes. Which commits did I miss?

Ok, I missed the other “apalis-tk1:” commits…

I would actually recommend using the tip of the -next branch unless you plan to explicitly skip certain enhancements.

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.