CAN Bus: using MCP2515 with Omega2

DumTux

@luz @Lazar-Demin @crispyoz and all!
I am still having trouble with CAN bus driving.

Current behavior

I set GPIO11 as input and load the MCP251x kernel module as per above discussion.
Now enable can0 and send packets using these commands.

root@OpenWrt:~# ip link set can0 up type can bitrate 125000
root@OpenWrt:~# cansend can0 01a#11223344AABBCCDD

Screenshot from 2022-11-13 23-25-25.png

I can see the waveform on bus by oscilloscope correctly.
Restart the bus as loopback mode to test somthing different.

root@OpenWrt:~# ip link set can0 down
root@OpenWrt:~# ip link set can0 up type can bitrate 125000 loopback on

Now the INT# (GPIO11) falls to LOW. MCP2515 stopped working.
*** MCP2515 does not recover even though I disable/enable the bus again like this.

root@OpenWrt:~# ip link set can0 down
root@OpenWrt:~# ip link set can0 up type can bitrate 125000

I have to turn off the board power and turn it on again to make MCP2515 INT# recovered.
dmesg shows nothing except success logs like this during all these operation.

...
[   68.586340] mcp251x spi0.1 can0: MCP2515 successfully initialized.
[   69.759118] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[  124.360819] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
...

The same situation goes for when I connect external sensor module, that emits CAN message periodically.
As soon as any external packet is coming in, the MCP2515 INT# falls to LOW. I can read nothing via candump.
All this behavior were the same no matter of setting GPIO11 as IN or not before loading the MCP251x kernel module.

Questions

Is this still IRQ problem?
Is there any way to check MCP2515 resistor values using canutils package commands?
Is there other reading method except candump ? For example, instead of inturrupt-based candump, manual polling.

DumTux

I am going to try to modify the bootloader to not handle GPIO11 for the dock power supply.
There is a bootloader on OnionIoT GitHub account, but it seems like outdated.
And I could not find the current OpenWrt 22.03 build using it.

Thus, I guess GPIO11 handling is somewhere patched inside OpenWrt 22.03's specific config files.
I could see some MediaTek related config patches under openwrt/package/boot/uboot-mediatek/.
There I either cannot find specific configs related to Omega2.
As MT76x8 is used in router products a lot, I don't believe the Omega2 specific config will be under this location.

Where can I find the OpenWrt 22.03 bootloader for Omega2?

Lazar Demin

@DumTux The bootloader is independent of the firmware. If you've reflashed your Omega2, it will still be running the factory bootloader.

The factory bootloader is compiled from this source code: https://github.com/OnionIoT/omega2-bootloader/
GPIO11 is set high to be compatible with the reset button on the Omega2 Docks. You can find that here in the bootloader: https://github.com/OnionIoT/omega2-bootloader/blob/master/lib_mips/board.c#L3028

When you've compiled your own bootloader, follow these instructions to update your device: http://docs.onion.io/omega2-docs/Web-Recovery-flash-bootloader.html

DumTux

void gpio_init(void)
{
  ....
  RALINK_REG(RT2880_REG_PIODIR+0x04)=val;

  /*
  //zh@onion.io
  //setting GPIO 11 High, required for the reset button to work
  val=RALINK_REG(RT2880_REG_PIODIR);
  val|=1<<11;
  RALINK_REG(RT2880_REG_PIODIR) = val; // GPIO 11 direction output
  val=RALINK_REG(RT2880_REG_PIODATA);
  val|=1<<11;
  RALINK_REG(RT2880_REG_PIODATA) = val; // GPIO 11 High
  */

  //jeffzhou@onion.io
  //adding for read wifi MAC address.
  unsigned char macbuf[6];
	raspi_read(macbuf, CFG_FACTORY_ADDR - CFG_FLASH_BASE + 0x04, 6);
	printf("wifi mac address = %02X%02X%02X%02X%02X%02X.\n",
      macbuf[0],macbuf[1],macbuf[2],macbuf[3],macbuf[4],macbuf[5]);
}

I commented the GPIO11 related part in the bootloader source code, and built it.
Just used make command.

After entering to Web recovery mode on Omega2's boot, I went to uBoot upgrade page.
There was Very dangerous warning, but I proceeded.
And after done, that dangerous result happened - not booting.

Screenshot from 2022-11-18 07-25-31.png

Is there some make option to build a bootloader specfic for Omega2+ ?

DumTux

As a comparison, this is normal booting screenshot from the factory bootloader.
It is showing DRAM size 128MB, while my above wrong bootloader shows as 64MB.
Also, flash memory is wrongly recognized.

Screenshot from 2022-11-18 10-05-07.png

Lazar Demin

@DumTux Make sure to run setup_env.sh and then you can use build.sh to build the bootloader binaries.

DumTux

@Lazar-Demin
How can I build a U-Boot image for Omega2+ ?

crispyoz

@DumTux The process is:

git clone https://github.com/OnionIoT/omega2-bootloader/
cd omega2-bootloader
./setup_env.sh
chmod +x build.sh
./build.sh

This produces 2 files:

uboot-omega2-<date>.bin
uboot-omega2p-<date>.bin

The latter is the Omega2+ uboot

DumTux

@crispyoz @Lazar-Demin
Yes, it worked. I choose the omgega2-bootloader instead of omega2p-bootloader accidentally.
After soldering with a brand new Omeba2S+ module, I carefully upgraded bootloader.

Here's the pre-compiled bootloader for others' future reference.
https://github.com/dumtux/omega2-bootloader/releases/tag/tower-bootloader-v0.1

After disabling GPIO11 default behavior from Omega2's bootloader, I could see some different behavior of MCP2515 kernel driver.
I could see some short impulses while initializing MCP2515 driver and enabling can0 interface.
I didn't see such impulses before with the default bootloader.

I'll keep posting further results.

Gerhard Bertelsmann

@DumTux
AFAIK the main problem is related to the wrong GPIO/IRQ mapping:
https://forum.openwrt.org/t/can-mcp2515-gpio-irq-problem/92879/3

Maybe luz or Lazar could give a hint ?

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.

Screenshot from 2022-12-06 19-16-59.png

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.