Hi,
FInal got my Fitlet 2 with FC-PCI card and am trying to see if will work with a RAK2247 Lora Concentrator, currently up to trying to reset the card via pin 22 using 'sys/class/gpio', but can not find any documentation on the PCI slot of the FC_PCI card.
I did find FC-PCI fitlet2 FACET Pinout description table but it only list the M.2 slot (Unless I'm reading it wrong).
Can anyone provide information on the PCI pinout and there mapping to the GPIO's?
FC-PCI GPIO
Moderator: Andrey.Mazlin
Re: FC-PCI GPIO
You should be able to find the schematic files of the FC-PCI at the following link:
http://fit-pc.com/wiki/index.php?title= ... rds#FC-PCI
http://fit-pc.com/wiki/index.php?title= ... rds#FC-PCI
Re: FC-PCI GPIO
Thanks for the reply Tamir,
What I am looking for is the GPIO number attached to the WIFI_RST# line as I need to control that pin via the /sys/class/gpio/gpio$WIFI_RST_PIN.
Just like the front led example on the wiki http://fit-pc.com/wiki/index.php?title= ... front_LEDs
the script I want to run is:
What I am looking for is the GPIO number attached to the WIFI_RST# line as I need to control that pin via the /sys/class/gpio/gpio$WIFI_RST_PIN.
Just like the front led example on the wiki http://fit-pc.com/wiki/index.php?title= ... front_LEDs
the script I want to run is:
Code: Select all
#!/usr/bin/env bash
# change pin
IOT_SK_SX1301_RESET_PIN=436 # Front Yellow LED 1, Change to GPIO of mPCI pin 22.
echo "Accessing concentrator reset pin through GPIO$IOT_SK_SX1301_RESET_PIN..."
WAIT_GPIO() {
sleep 0.1
}
iot_sk_init() {
# setup GPIO
echo "$IOT_SK_SX1301_RESET_PIN" > /sys/class/gpio/export; WAIT_GPIO
# set GPIO as output
echo "out" > /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/direction; WAIT_GPIO
# write output for SX1301 reset
echo "1" > /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/value; WAIT_GPIO
echo "0" > /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/value; WAIT_GPIO
# set GPIO as input
echo "in" > /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/direction; WAIT_GPIO
}
iot_sk_term() {
# cleanup GPIO
if [ -d /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN ]
then
echo "$IOT_SK_SX1301_RESET_PIN" > /sys/class/gpio/unexport; WAIT_GPIO
fi
}
iot_sk_term
iot_sk_init
sleep 3
./lora_pkt_fwd
Re: FC-PCI GPIO
While waiting on some answers, I’ve been digging and found the fitlet2 blocks diagram PDF and having a guess that one of the pcie block should be connected to the mPCIe on the FC-PCI card.
I went looking at the Intel datasheet PDF for the E3950 and found that the PCIe is the same as the N- and J- series processors. So off too the N- and J- series datasheets.
Now looking at N- and J- series datasheets (334817-001), we find in table 2-18, PCIE_PERST[3:0]_N, type GPIO, with note: "Operates in GPIO Mode, These signal need to be assigned by BISO based on design implementation".
don't know where to go from there?
did a dump with lspci -v and got 2 PCI bridge:
I went looking at the Intel datasheet PDF for the E3950 and found that the PCIe is the same as the N- and J- series processors. So off too the N- and J- series datasheets.
Now looking at N- and J- series datasheets (334817-001), we find in table 2-18, PCIE_PERST[3:0]_N, type GPIO, with note: "Operates in GPIO Mode, These signal need to be assigned by BISO based on design implementation".
don't know where to go from there?
did a dump with lspci -v and got 2 PCI bridge:
Code: Select all
00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 (rev fb) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 120
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: c1100000-c11fffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Device 0000:0000
Capabilities: [a0] Power Management version 3
Capabilities: [100] #00
Capabilities: [140] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [200] L1 PM Substates
Kernel driver in use: pcieport
Kernel modules: shpchp
00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 121
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: c1000000-c10fffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Device 0000:0000
Capabilities: [a0] Power Management version 3
Capabilities: [100] #00
Capabilities: [140] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [200] L1 PM Substates
Kernel driver in use: pcieport
Kernel modules: shpchp
Re: FC-PCI GPIO
Our R&D are investigating this.
I will return to you asap.
I will return to you asap.
Re: FC-PCI GPIO
Our R&D determined that FPCI P5-22 (WIFI_RST#) is not controlled by GPIOs
But theoretically you could use other lines:
FPCI P5-20 (W_DISABLE#)
FPCI P4-54 (W_DISABLE2#)
If the above could be suitable, we could work to get you the information.
But theoretically you could use other lines:
FPCI P5-20 (W_DISABLE#)
FPCI P4-54 (W_DISABLE2#)
If the above could be suitable, we could work to get you the information.
Re: FC-PCI GPIO
Thanks Tamir,
Can you confirm with R&D that the WIFI_RST# is pull down (low), as I might be able to reset the card via the USB interface but pin22 need to be low.
would be a big disappointment if I can't use the mPCIe for this card as the Fitlet2 is performing beyond expectations.
Thanks again for your help.
Can you confirm with R&D that the WIFI_RST# is pull down (low), as I might be able to reset the card via the USB interface but pin22 need to be low.
would be a big disappointment if I can't use the mPCIe for this card as the Fitlet2 is performing beyond expectations.
Thanks again for your help.
Re: FC-PCI GPIO
I'll confirm that with our R&D and get back to you.
Re: FC-PCI GPIO
our R&D replied that the WIFI_RST# pin is controlled directly by the SoC and should have a pull down but we cannot control.