Hello!
I’m using GatewayOS with a Brazillian gateway (Radioenge) on a Raspberry Pi 3. This hardware has an issue that was first reported on GPIO 7 reset pin busy · Issue #71 · brocaar/chirpstack-gateway-os · GitHub - the GPIO7 pin (reset) is busy, which prevents ConcentratorD to run. Is there a way to solve it without recompiling the entire GatewayOS?
The hardware used to work with GW OS 3.3.2 but did not worked after GW OS 3.3.3.
Hey there, I found a solution for my problem.
I had to download this precompiled file (firmware/spi0-2cs.dtbo at master · raspberrypi/firmware · GitHub) and put it into my SD card on folder /boot/overlays .
Then I edited the file /boot/config.txt (only the last line). The last line must be like
dtoverlay=spi0-2cs,cs1_pin=<another free pin different from 7>
In my case I used pin 31 for Raspberry Pi 3 (GPIO6) which is unused and it worked.
Hi Rodrigo, I created an account just so I could thank you A LOT for the solution you provided !!
I was stuck with this problem for quiet a long time… Something around 10 days :’)
You can’t imagine how relieved I am right now haha, my gateway is finally working, thanks again ! 
Hi !
The GatewayOS with a Brazillian gateway (Radioenge) is working ok for me on a Raspberry PI 3+. I had opened the Issue #71 and now it’s working OK with these parameters that I’ve set for GatewayOS v3.5.1 :
File chirpstack-concentratord/sx1301/global.toml:
model=“generic_au915”
model_flags=[“GNSS”,]
reset_pin=7
File /boot/config.txt
Uncomment this line:
dtoverlay=spi0-1cs
The channels from chirpstack-concentratord/sx1301/channels.toml should be defined according with Brazilian restrictions. Just for example: TTN AU915 uses channels from 8 to 15 and 65.
I hope this could help anyone here.
Hi everyone! I’m trying to update my gateway to GatewayOS 4.6.0 but I’m facing this old problem. I’ve tried to edit /boot/config.txt to include the dtoverlay line (now the file spi0-2cs.dtbo is already included in the SD card image):
dtoverlay=spi0-2cs,cs1_pin=<another free pin different from 7>
Also, I tried to add option sx1301_reset_pin '25' to /etc/config/chirpstack-concentratord for config sx1301 as suggested in this topic. None of these solutions worked and I keep reading on the system log:
Configuring reset pin, dev: /dev/gpiochip0, pin: 17
which makes me wonder whether the gateway is acknowledging my reset pin configuration. Any ideas on how to properly set up the reset pin? Thank you!
Hi, Rodrigo! Some news about 4.6.0 (ou 4.5)? We need Mesh, available from 4.5.
This isn’t really about the version of Chirpstack Gateway OS, but how to configure Raspbian to not reserve that pin for SPI CS1. Since Kernel 5.4.51, Raspbian would reserve GPIO8 and 7 for SPI CS0 & CS1 respectively. However, the Semtech reference gateway design (and thus gateways based off this design) use GPIO7 as a reset signal.
There are two pins that are connected from the HAT to the GPIO: Chip Select (SPI0 CS0, which is GPIO8) and RESET (e.g. GPIO7). The exact pin used for the reset signal may differ on other boards (e.g. IMST ic880A).
Here, it was detailed what’s happening: Upgrade to kernel 5.4.51-v7+ breaks Raspberry Pi Hats that use SPI and expect GPIO 7 to be free · Issue #162 · Lora-net/lora_gateway
And here was the original discussion: Upgrade to 5.4.51-v7+ breaks Hats that use SPI and expect GPIO07 to be free (LoRa Gateways) · Issue #3749 · raspberrypi/linux