Apalis iMX8 PCIe on VxWorks 7

Technical Support
,
1

We are porting an Apalis i.MX8 board to VxWorks 21.07. Our PCIe connection (x43) to a PolarFire FPGA is not working with VxWorks(the device doesn’t enumerate). It works fine with Toradex linux.

We have also tried another SF2 FPGA card and verified that it is recognized letting us know the slot does work.

Under vxWorks reset is low at the slot. (resetGpio is set to gpio0, 30, 1, 1, 100 )

Is 30 correct for the PCIe reset?

2

Hi Dan,
Since another SF2 FPGA card was detected correctly, I would suggest starting by investigating the differences between the two cards. Regarding your last request, could you please provide details about the resetGpio parameters? Unfortunately, I have no experience with VxWorks.

3

We don’t have the IP for the SF2, it is a PCI demo build from Microsemi. Our guess is that they simply ignore the reset input so that card works.

Do you know where in the Toradex Linux source the reset gpio is manipulated? I haven’t found anything in the Linux or U-Boot code. I should note that I am using tfptboot to run vxworks from the uboot prompt.

A few parameters are passed to the Freescale PCIe controller (this is form their imx8qm-mek vxworks BSP).

&pciea
{
status = “okay”;
gpio-binds = <&gpio4 27 1 0 100 /* GPIO_CLKREQ_INDEX /
&gpio4 9 1 1 100 / GPIO_DISABLE_INDEX /
&gpio0 26 1 1 100 / GPIO_RESET_INDEX /
&gpio1 13 1 1 100>; / GPIO_EPDEV_INDEX */
};
These set:
gpio bank, pin#, input/output (output == 1), high/low (high == 1), delay)

The IMX controller is up as is the PLX host bridge. The only thing out of place is the reset line at the connector.

4

Since you mentioned X43 I assume you are using the Apalis Evaluation board with your Apalis i.MX8 SOM, Is it correct? On the Apalis Evaluation board PCI reset line is driven by the SOC RESET_MOCI# line . “This pin is active low. This pin is driven low at boot up. This is an open-drain signal with a 10k pull-up resistor on the module.”
Yes you can also control this pin by LSIO.GPIO0.IO30
image

But please note that this signal is also controls the Apalis Evaluation board Step-Down Controller which powers 3.3 and 5v power rails. So holding it ACTIVE (LOW) too long will de-power not only the carrier board peripherals, but Apalis i.MX8 SOM itself.

You can easily monitor the RESET_MOCI# signal by connecting an oscilloscope or logic analyzer to pin 26 of connector X4.

5

This isn’t making much sense to me. Pin26 starts at zero and then transitions to 3.3v during Linux kernel boot. At the uboot prompt Pin26 reads zero. This leads me to believe that something in the Linux source is releasing the reset and my VxWorks OS isn’t doing this.

I tried manipulating GPIO0_30 via uboot and vxworks and neither has any effect on the voltage I read at Pin26.

I should note that I am not using the full toradex device tree structure as the VxWorks drivers didn’t seem to handle the nesting of elements below IMX8 subsystems (like lsio).

6

I can confirm that Pin26 can be toggled by SCU_GPIO0_02 (LSIO_GPIO0_IO30). You can verify it by loading the Toradex Minimal Image 5.7.5 and manipulate pin 26 via /sys/class/gpio/ interface. Pin 26 corresponds to gpio510

7

It appears that I was missing the correct pin control settings for SCU_GPIO_02. I added a config to set that pin to GPIO mode in the pciea iomux.

iomux_pciea: iomux_pciea
    {
    pin-set = <
        SC_P_PCIE_CTRL0_CLKREQ_B    0xde000021
        SC_P_PCIE_CTRL0_WAKE_B      0xdc000021
        SC_P_SCU_GPIO0_02           0xde000021 /* set to gpio mode */
        SC_P_PCIE_CTRL0_PERST_B     0xde000021 
        SC_P_USDHC2_RESET_B         0xde000021
        SC_P_LVDS1_I2C0_SDA         0xde000000
        >;
    };