chirpstack / chirpstack-gateway-os

OpenWrt based gateway images including ChirpStack components.

Home Page:https://www.chirpstack.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GPIO 7 reset pin busy

fernandobarreto opened this issue · comments

Hi,
The chirpstack-gateway-os 3.3.3 has the chirpstack-concentratord v3.0.3 version, which implements the overwriting reset-pin for RPi shields.

However, some gateway boards have the reset pin allocated at GPIO 7 pin, which is also allocated to SPI0 CS1 on RPi versions (https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md). When the chirpstack-concentradord tries to start it crashes with EBUSY error on this GPIO 7 pin.

In order to fix it, the chirpstack-gateway-os image should include the /boot/overlays/spi0-2cs.dtbo file in Yocto structure in order to enable the config parameter "dtoverlay=spi0-2cs,cs1_pin=<another free pin different from 7>" in /boot/config.txt. This will reallocate the SPI0 CS1 GPIO 7 pin to a different GPIO pin, and the concentratord will start correctly with GPIO 7 reset pin.

I hope this can help to improve Gateway OS.

Could you add which boards are using GPIO7 for reset (I believe it is the Radio Engine board, but are there others)? And have you tested this to validate that this solves the issue?

In your email you mentioned:

Well, I have two lora gateways boards (radioenge brand) from Brazil (https://www.radioenge.com.br/solucoes/iot/18-gateway-lorawan.html) and they work OK with GatewayOS 3.3.2 (concentradord 3.0.2, if I change the gateway model in global.toml to "generic_au915" and reset_pin to 7. The configuration that I found to be similar is RAK - RAK2246, AU915, Channels 8 - 15 + 65.

If it would work with Gateway OS 3.3.2, then are we sure this change is needed? While you can override the reset pin now in the Concentratord config, there was no change with regards to the /boot/overlays/spi0-2cs.dtbo overlay (I don't think this was ever included).

I would be interested why it worked with GW OS 3.3.2 and not 3.3.3.

This bypass works on a Raspberry Pi 3 with with a Gateway Radioenge board (RD43HATGPS) running GW OS 3.3.3 . So, it really solves the problem.

The GW OS 3.3.2 runs OK with the same gateway board. My supposition is the "overwriting reset-pin for RPi shields" chirpstack-concentratord feature, or even any differences in SPI code on kernel version (GW OS 3.3.2 uses 4.19.126-v7, GW OS 3.3.3 uses 5.4.72-v7). I'm looking for this differences but yet without success.

I have been looking into this a bit, but I could not find the overlay in the meta-raspberrypi Yocto BSP: https://github.com/agherzan/meta-raspberrypi/blob/dunfell/conf/machine/include/rpi-base.inc#L17. I think first the meta-raspberrypi BSP layer needs to include the overlay, before I can include it into the GW OS.

But, if you add the string "overlays/spi0-2cs.dtbo" in the RPI_KERNEL_DEVICETREE_OVERLAYS in Yocto BSP above before Yocto build, it will generate it, right ?

Let me check, I might be able to extend that value. Note that the BSP layer itself can't be changed as it is a git submodule which is pulled in.

This should be fixed by 9090ce3.