Apalis TK1 Datasheet does not identify kernel assignments for user GPIOs

Technical Support
, , ,
#1

We had picked the Apalis TK1 GPIO7 (GPIO3_PDD.01) as an input function based on the TK1 datasheet, and were surprised to find the port in electrical conflict with the driving device as well as being unable to export the port (see forum Question 15272). The TK1 pins function list identifies X1 Pin 15 (PEX_L0_RST_N) with the SFIO0 function on GPIO3_PDD.01 (GPIO7) as “pe0_rst_I” which implies the port defaults to an input similarly to “pe_wake_I”. Since there is no mention of pe0_rst_I in table 6-24 (additional PCIe Control Signals), and GPIO7 is identified in table 6-4 of the GPIOs section 6.2 as PEX_L0_RST_N with no further details, one is led to believe that pe0_rst_I in the pins function table defines the port as an input by default.

GPIOs section 6.2 cautions about selecting the correct type of GPIO but the warning appears strictly aimed at the electrical capability of the IO. Table 6-4 does not identify the kernel default configurations of the GPIO ports, making it impossible for designers to pick appropriate default-configured GPIOs through the datasheet alone. In the case of GPIO7, it is set as an output on the TK1 Apalis eval design to fix an errata on a PCIe expander device, and this configuration appears to be retained in the kernel by default. It would be very helpful to include such information in the datasheet if it is a fixed feature in the kernel.

#2

We had picked the Apalis TK1 GPIO7 (GPIO3_PDD.01) as an input function based on the TK1 datasheet, and were surprised to find the port in electrical conflict with the driving device as well as being unable to export the port (see forum Question 15272).

No need to be surprised at all. Should you have read the whole question you would have realised that simply specifying pex_perst=0 on the kernel command line as indicated in the following commit message would have solved your issue.

The TK1 pins function list identifies X1 Pin 15 (PEX_L0_RST_N) with the SFIO0 function on GPIO3_PDD.01 (GPIO7) as “pe0_rst_I” which implies the port defaults to an input similarly to “pe_wake_I”. Since there is no mention of pe0_rst_I in table 6-24 (additional PCIe Control Signals), and GPIO7 is identified in table 6-4 of the GPIOs section 6.2 as PEX_L0_RST_N with no further details, one is led to believe that pe0_rst_I in the pins function table defines the port as an input by default.

You do realize that what you are talking about is purely a hardware datasheet nothing to do with software where more or less anything is configurable anyway.

GPIOs section 6.2 cautions about selecting the correct type of GPIO but the warning appears strictly aimed at the electrical capability of the IO.

Yes, as it is just a hardware datasheet and nothing else.

Table 6-4 does not identify the kernel default configurations of the GPIO ports, making it impossible for designers to pick appropriate default-configured GPIOs through the datasheet alone.

But what exact Linux kernel resp. BSP version should we describe? This is really a software configuration question outside the scope of any such hardware datasheet but rather addressed on our developer website or this very community forum.

In the case of GPIO7, it is set as an output on the TK1 Apalis eval design to fix an errata on a PCIe expander device, and this configuration appears to be retained in the kernel by default.

Yes, it’s just a default of our demo image easily re-configurable.

It would be very helpful to include such information in the datasheet if it is a fixed feature in the kernel.

No, such information does definitely not belong into any hardware datasheet, sorry.

#4

Yes. point taken; it’s a hardware datasheet. The software configuration doesn’t belong there.
I know that, as you point out, the port configurations can be simply set by recompiling the kernel with the minor changes described in the other forum question (I had read the whole thread and understood the remedy). That was the easy part.

The default state of the GPIOs and other TK1 configurations in your stock BSP releases is important to our client since they are dependent on kernel compatibility of a particular NVIDIA library. Every recompile of the kernel risks breaking something since the library is not maintained to the latest kernel. We went through hell just trying to avoid recompiling early BSP 2.7.2 to get an LCD touch panel to run via HDMI. It was lucky that the library remained compatible with the kernel in BSP 2.8b3 release, allowing our client to compile the necessary change to light up the LCD. They may not be so lucky in the future if the kernel gets well ahead of the library, hence their extreme sensitivity to changes that require recompiling the kernel.

Finally, perhaps you can explain something I just discovered. The Apalis Arm Carrier Board Design Guide, presumably a hardware document, includes the very statements in Table 37 I had suggested for the datasheet. Although software configuration is involved, the description fundamentally reveals a hardware configuration of GPIO7 and GPIO8 supporting the Apalis eval board. My mistake was that I hadn’t gone back to the Carrier guide when we added the GPIO late in the project. In my haste, I simply picked a port that appeared to default as input in the function list of the datasheet. I kinda wish the GPIO table in the TK1 datasheet was identical to that in the Carrier guide, but it was my bad for not consulting the latter.