CAN Bus: using MCP2515 with Omega2

[luz]

@Gerhard-Bertelsmann Yes, the 19.07 version of gpio-mt7621.c interrupt routing implementation is broken for GPIO interrupts assigned via DT.

I made ugly patches to fix that back then, I can dig them out if someone wants to use them, but I can't exactly recommend (it was kind of an emergency hack for an urgent project).

As far as I know, the issue should be fixed in the 22.03 version of gpio-mt7621.c, as the entire driver has been reworked to align with other modern GPIO drivers and handles the banks differently.

But I haven't had the chance to test it so far, and the link to the OpenWrt forum you posted saying it is not yet fixed in 21.02 makes me doubt a bit, because I thought the rework already happened in the 21.02 time frame, but I can't verify or test that right now.

[DumTux]

@Gerhard-Bertelsmann
I experienced similar error messages when I used the wrong GPIO number.
For example, I tried this.
interrupts = <75 0x02>
And it gave very similar error as yours on kernel module loading.

As far as I used the right GPIO number 11, the kernel module loading was just successful.
I don't have a clue if this means the issue was eliminated in 22.03.

When I connect two boards via CAN bus, I could only enable CAN driver from one board.
Currently, I am in a different situation after disabling GPIO11's default behavior of the bootloader.
I can enable both side drivers. And each board can send CAN packets by cansend.
However, the interrupt is not invoking and candump still prints nothing.

[Gerhard Bertelsmann]

@luz said in CAN Bus: using MCP2515 with Omega2:

I made ugly patches to fix that back then, I can dig them out if someone wants to use them, but I can't exactly recommend (it was kind of an emergency hack for an urgent project).

I would be interested in this patch

As far as I know, the issue should be fixed in the 22.03 version of gpio-mt7621.c, as the entire driver has been reworked to align with other modern GPIO drivers and handles the banks differently.

I switched to 22.03 but the problem is still present

[DumTux]

I just did another experiment.
I disconnected external sensor.

Omega2 -> MCP2515 -> (open) -> Oscilloscope

If I enable the CAN bus like this, I can see output CAN packet from the oscilloscope.

ip link set can0 up type can bitrate 125000
cansend can0 01a#112233

Next, I enabled CAN bus with loopback mode.

ip link set can0 down
ip link set can0 up type can bitrate 125000 loopback on
cansend can0 01a#112233

No CAN packet waveform I can see!
To see it again, I should re-enable the CAN bus without loopback mode.

ip link set can0 down
ip link set can0 up type can bitrate 125000 loopback off
cansend can0 01a#112233

Any thought from this loopback mode behavior?

[DumTux]

@luz
I also would like to see your patches as @Gerhard-Bertelsmann said.
Is it somewhere in public repo?

[Gerhard Bertelsmann]

@DumTux said in CAN Bus: using MCP2515 with Omega2:

Next, I enabled CAN bus with loopback mode.

ip link set can0 down
ip link set can0 up type can bitrate 125000 loopback on
cansend can0 01a#112233

No CAN packet waveform I can see!

that's the usual behaviour in loopback mode. Packets are not transmitted to the transceiver.
I use the loopback mode for testing purpose. If this works (received the same data as send) everything is fine with the communication to the CAN controller.

[luz]

@Gerhard-Bertelsmann said in CAN Bus: using MCP2515 with Omega2:

I switched to 22.03 but the problem is still present

Ok, interesting! So the rework did not catch that. Maybe I mixed it up in hindsight with the initialisation of GPIO output's initial value (did not work as expected in 19.07, I had to patch that too back then, but definitely this now works in 22.03 as is)

I would be interested in this patch

Here's the patch.

Note that this is a patch on top of a pristine openwrt v19.07.8 tree, which consists of adding kernel patches, which then are applied in the process of building the kernel. So the patch is kind of a "meta-patch", doing the following:

• (up to line 607) updates the gpio-mt7621.c to a newer version from upstream. I had forgotten about that - it seems this newer version is quite near to today's 22.03 version.
• (lines 649..717) patches that new driver to fix the IRQ problem. This patch is ugly because it needs to swap the private irq_ops with a modified copy to implement the select callback.
• (lines 608..648) patches OMEGA2.dtsi and (lines 718..) adds a new version for mt7628an.dtsi called mt7688newgpio.dtsi because the new driver now addresses the gpios by number, no longer by bank+offset.

I package such changes into openwrt tree (meta)patches rather than forking the openwrt tree, because different projects need different patches, and I don't want a multitude of trees or branches, and keep the changes versioned per project in my own feeds, not openwrt.

The p44build script helps with that workflow in case you are interested.

[DumTux]

@luz
I tried p44b build script first of all.
And I got this result.

It seems like the build script doesn't support OpenWrt 22.03 yet.
It totally make sense, as many file locations and contents are updated to kernel 5.10, it would mess if I force to apply all patches globally.

---

I am now on the way to manually applying the GPIO patch to OpenWrt 22.03.
But it's not easy for me as the gpio-mt7621.c seems like changed.

[luz]

@DumTux the p44b script works from the information in the p44build directory you specify at init. It seems you tried with an older project that was still on 18.06.4. p44b works with 22.03 but I don't have a complete setup yet exactly because of the various detail issues I am still having.

But it's not easy for me as the gpio-mt7621.c seems like changed.

I agree , it takes an awful lot of time to dig into such things and get it right.

But by now, gpio-mt7621.c seems to be Linux mainline

Looking at the commit history of that file in Linux mainline, it seems that there were several changes related to IRQ handling in the past 2 years.

Maybe it would make more sense to try to use that latest mainline version and see if the changed IRQ handling now works correctly. Hoping this seems not too unrealistic to me - all the changes mostly seem to be generalisations, i.e. replacing mt7621 specific things by generic mechanisms that work for many other drivers, too.

[DumTux]

Thank you @luz
Right now, I gave up solving this MCP2515 issue on OpenWrt 22.03.
We decided to move to ESP32 as the CAN bus was a critical requirement for our projects.
Although this problem is not solved on my side, I hope it could be a little help for people's future projects related to Omega2 + MCP2515.