vexorg
(Michael)
October 27, 2024, 4:00am
1
Greetings all, I’m wondering if anyone’s been able to make use of the SPI pins in the bpi-r4 GPIO header. I’m interested in building a monitor using an OLED display like this one , ideally using the luma-lcd library.
In another thread for the r3 , frank-w was attempting the same thing. It’s unclear from that thread if it ever worked out, though I’ve heard the r3 has similar hardware as the r4.
Curious if anyone has any pointers here.
1 Like
There is a problem with the NVME SSD. I think you have to remove 2 resistors first…
frank-w
(Frank W.)
October 27, 2024, 11:15am
4
I tried but cannot get display init to work…but have not tried luma-led with it. R3 and r4 using different soc,so hardware is different but basicly they have multiple spi,but maybe lumaled needs a exposed spidev device
vexorg
(Michael)
October 27, 2024, 4:43pm
5
I’m specifically looking at doing this in OpenWRT because I think the platform support for the R4 is probably best in that distro compared to upstream for now. I noticed what looks like a reference to SPI1 in one of the device tree files . I did also find a thread on the OpenWRT forum where someone made some progress accessing the spi1 device, but apparently it causes kernel panics.
According to the pinout diagram , it does look like SPI1 would be the right place to connect a display.
I’m curious how this relates to the i2c issue though? I read about the resistors messing up NVMe and SFP modules, but shouldn’t that be totally unrelated to the spi1 bus?
frank-w
(Frank W.)
October 27, 2024, 6:15pm
6
I think i2c issue is unrelated here, more i would suggest adding some printk to mtk_spi_set_cs and try again. Maybe cs pin is mapped to another function,but this should be handled properly…it looks like it is something related with interrupt handling
A bit more information is in the issue here,but suggested change seems not fixing it
opened 12:25PM - 07 Mar 24 UTC
target/mediatek
bug
SNAPSHOT
Self Built Image
### Describe the bug
The board crashes with a kernel panic as soon as the SPI d… evice is being used. Binding the device works, but sending data does not.
### OpenWrt version
r25404-e247763617
### OpenWrt release
SNAPSHOT
### OpenWrt target/subtarget
mediatek/filogic
### Device
Bananapi BPI-R4
### Image kind
Self-built image
### Steps to reproduce
Add the following definition to `mt7988a-bananapi-bpi-r4.dts`
```
&spi1 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
status = "okay";
spidev@0 {
compatible = "linux,spidev";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <500000>;
status = "okay";
};
};
```
After booting, register and bind the SPI device to spidev:
```
echo "spidev" > /sys/bus/spi/devices/spi1.0/driver_override
echo "spi1.0" > /sys/bus/spi/drivers/spidev/bind
```
Run a simple device test:
```
opkg update
opkg install spidev_test
spidev-test -D /dev/spidev1.0
```
### Actual behaviour
A kernel panic occurs. Here's mine:
```
[ 130.687392] SError Interrupt on CPU3, code 0x00000000bf000002 -- SError
[ 130.687404] CPU: 3 PID: 3275 Comm: spidev_test Not tainted 6.1.80 #0
[ 130.687410] Hardware name: Bananapi BPI-R4 (DT)
[ 130.687412] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 130.687416] pc : mtk_spi_set_cs+0x54/0x7c
[ 130.687427] lr : spi_set_cs+0x88/0x1e0
[ 130.687433] sp : ffffffc00c643cb0
[ 130.687435] x29: ffffffc00c643cb0 x28: ffffff80c0d30000 x27: 0000000000000000
[ 130.687442] x26: 0000000000420084 x25: ffffff80c3e40358 x24: ffffff80c4678da0
[ 130.687447] x23: ffffff80c0a20400 x22: 0000000000000000 x21: 0000000000000000
[ 130.687452] x20: 0000000000000000 x19: ffffff80c0a20400 x18: 0000000000000000
[ 130.687456] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 130.687460] x14: 0000000000000000 x13: 0000000258891970 x12: ffffff80c0a06a80
[ 130.687464] x11: 0000000000000065 x10: 00000000000002b8 x9 : 0000000000000001
[ 130.687468] x8 : 0000000000895440 x7 : 0000000002e4ecfa x6 : 0000000000000023
[ 130.687472] x5 : 0000000000000000 x4 : ffffff80c094c800 x3 : ffffffc008dfd018
[ 130.687476] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff80c094cd80
[ 130.687482] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 130.687484] SMP: stopping secondary CPUs
[ 130.687488] Kernel Offset: disabled
[ 130.687489] CPU features: 0x00000,00020004,0000400b
[ 130.687492] Memory Limit: none
```
### Expected behaviour
The SPI test runs successfully.
### Additional info
I initially encountered this problem while trying to use the SPI interface to attach a display. Using spidev is the easiest way to trigger the kernel panic.
### Diffconfig
```text
CONFIG_TARGET_mediatek=y
CONFIG_TARGET_mediatek_filogic=y
CONFIG_TARGET_mediatek_filogic_DEVICE_bananapi_bpi-r4=y
CONFIG_PACKAGE_cgi-io=y
CONFIG_PACKAGE_kmod-spi-dev=y
CONFIG_PACKAGE_liblucihttp=y
CONFIG_PACKAGE_liblucihttp-ucode=y
CONFIG_PACKAGE_luci=y
CONFIG_PACKAGE_luci-app-firewall=y
CONFIG_PACKAGE_luci-app-opkg=y
CONFIG_PACKAGE_luci-base=y
CONFIG_PACKAGE_luci-light=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-mod-network=y
CONFIG_PACKAGE_luci-mod-status=y
CONFIG_PACKAGE_luci-mod-system=y
CONFIG_PACKAGE_luci-proto-ipv6=y
CONFIG_PACKAGE_luci-proto-ppp=y
CONFIG_PACKAGE_luci-theme-bootstrap=y
CONFIG_PACKAGE_luci-theme-openwrt-2020=y
CONFIG_PACKAGE_rpcd=y
CONFIG_PACKAGE_rpcd-mod-file=y
CONFIG_PACKAGE_rpcd-mod-iwinfo=y
CONFIG_PACKAGE_rpcd-mod-luci=y
CONFIG_PACKAGE_rpcd-mod-rrdns=y
CONFIG_PACKAGE_rpcd-mod-ucode=y
CONFIG_PACKAGE_ucode-mod-html=y
CONFIG_PACKAGE_ucode-mod-math=y
CONFIG_PACKAGE_uhttpd=y
CONFIG_PACKAGE_uhttpd-mod-ubus=y
```
### Terms
- [X] I am reporting an issue for OpenWrt, not an unsupported fork.
frank-w
(Frank W.)
November 1, 2024, 9:27am
7
Could you try this?
--- a/arch/arm64/boot/dts/mediatek/mt7988a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a.dtsi
@@ -345,7 +345,7 @@ spi1: spi@11008000 {
reg = <0 0x11008000 0 0x100>;
interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&topckgen CLK_TOP_MPLL_D2>,
- <&topckgen CLK_TOP_SPI_SEL>,
+ <&topckgen CLK_TOP_SPIM_MST_SEL>,
<&infracfg CLK_INFRA_104M_SPI1>,
<&infracfg CLK_INFRA_66M_SPI1_HCK>;
clock-names = "parent-clk", "sel-clk", "spi-clk",
and removing the “spi-” from hclk name…driver looks for “hclk”
dangowrt
(Daniel Golle)
November 3, 2024, 3:24am
8
OpenWrt should now support using SPI1
committed 03:40AM - 01 Nov 24 UTC
The clocks for SPI busses were named wrongly which resulted in the
spi-mt65xx dr… iver not requesting them. This has apparently been
worked around by marking the clocks required for SPI0 which is used
for SPI-NOR and SPI-NAND flash chips as critical.
Fix the device tree for all 3 generic SPI host controllers and no
longer mark clocks as critical.
Signed-off-by: Daniel Golle <[email protected] >
3 Likes