DRA821U: Linux: Multiple MCAN CAN-FD peripheral support

Hi,

we found that there may be an older an older patch that was suggested for a previous PSDK 6.02, but we are now running on PSDKLA 7.2.

https://e2e.ti.com/support/processors/f/processors-forum/922168/faq-tda4vm-how-can-i-use-can-on-linux

Could you let us know what the latest status is on supporting CAN on Linux, specifically MCAN CAN-FD on Linux, and what the best path is currently to enable multiple CAN-FD on Linux (using GESI board)?

Thanks!

--Gunter

Hi Gunter,

Currently we do not have CAN support on DRA821 as a part of the SDK, the FAQ you pointed out is on DRA829/TDA4VM which is another SoC from the same family.

Having said that:

1. There are discussions happening internally on this requirement - I will keep you posted on that.

2. You can start with using the FAQ https://e2e.ti.com/support/processors/f/processors-forum/922168/faq-tda4vm-how-can-i-use-can-on-linux as the starting point. Ofcourse you will need to make changes to the device tree nodes wrt: Pinmux, Interrupt configuration and Transceiver enable code.

Regards,

Karan

Hello Karan,

I tried these patches on SDK 7.3 and tried to bring up CAN-FD on DRA821U. However I see these startup errors.

--

root@j7200-evm:~# dmesg | grep can
[ 12.119643] m_can_platform 40528000.can: m_can device registered (irq=13, version=32)
[ 12.277436] pinctrl-single 11c000.pinmux: pin PIN53 already requested by 2000000.i2c; cannot claim for 40568000.can
[ 12.545366] pinctrl-single 11c000.pinmux: pin-53 (40568000.can) status -22
[ 12.596340] pinctrl-single 11c000.pinmux: could not request pin 53 (PIN53) from group mcu-mcan1-pins-default on device pinctrl-single
[ 12.780981] m_can_platform 40568000.can: Error applying setting, reverse things back
[ 12.847679] m_can_platform: probe of 40568000.can failed with error -22
[ 74.097981] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[ 88.202667] can: controller area network core (rev 20170425 abi 9)
[ 88.220933] can: raw protocol (rev 20170425)

--

can0 seems to come up fine, but I've not been able to do signaling on it with CAN lines on J30 on the CP Board (I've cross verified that my setup works just fine with DRA829s). However, if I enabled loopback, I can see that working.

--

root@j7200-evm:~# ip link set can0 type can bitrate 1000000 dbitrate 5000000 fd on loopback on
root@j7200-evm:~# ip link set can0 up
[ 74.097981] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

root@j7200-evm:~# candump can0 &
[1] 911
root@j7200-evm:~# [ 88.202667] can: controller area network core (rev 20170425 abi 9)
[ 88.208913] NET: Registered protocol family 29
[ 88.220933] can: raw protocol (rev 20170425)

root@j7200-evm:~# cansend can0 113##2AAAAAAAA
can0 113 [04] AA AA AA AA
can0 113 [04] AA AA AA AA

--

Can you please check these pinmuxs on these patches? I have taken the patch as is without any modifications.

Hi Vai,

For can0:

I need to test these on my side, I do not have a DRA821 EVM handy with me so might take a couple of days.

I see one discrepancy wrt the schematics itself. The MCU MCAN0 transceiver's STB signal in one document is coming from WKUP_GPIO0_54 and in another is coming from  WKUP_GPIO0_58. Will you be able to make appropriate changes in the meantime? You need to change the stb-gpio of the node and also pinmux WKUP_GPIO0_58 instead of WKUP_GPIO0_58.

Regards,

Karan

Hi Karan,

I can try that out. My EVM is busy with another project - once I get some free time on it, I'll try swapping the SOM and try the pinmux changes.

Thanks

Vai

Hi Vai and Karan,

I also took a close look at the DRA821 patch. First applying the patch straight up, also getting the following

root@j7200-evm:~# dmesg |grep can
[ 6.820419] pinctrl-single 4301c000.pinmux: pin PIN38 already requested by 46000000.ethernet; cannot claim for 40528000.can
[ 7.202129] pinctrl-single 4301c000.pinmux: pin-38 (40528000.can) status -22
[ 7.379211] pinctrl-single 4301c000.pinmux: could not request pin 38 (PIN38) from group mcu-mcan0-gpio-pins-default on device pinc
trl-single
[ 7.483566] m_can_platform 40528000.can: Error applying setting, reverse things back
[ 7.701966] m_can_platform: probe of 40528000.can failed with error -22
[ 7.980716] m_can_platform 40568000.can: m_can device registered (irq=15, version=32)

The piece of the patch of the pin 38 is this:

+ mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-pins-default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xc0, PIN_INPUT, 7) /* (B18) WKUP_GPIO0_0 */
+ J721E_WKUP_IOPAD(0x98, PIN_INPUT, 7) /* (C9) MCU_MDIO0_MDIO.WKUP_GPIO0_54 */
+ >;
+ };

Maybe the issue is that we are touching PADCONFIG_38 register (with offset 0x98) (DRA821U datasheet page 75, Table 7-106), which controls GPIO0_39, while we should be touching a different PADCONFIG to control either GPIO0_54 or GPIO0_58, based on Karan's message.

First I think we need to check again, which GPIO pin is used, then get to the right PADCONFIG.

Hi Vai, quick side note, btw, with this kernel built from the SDK 7.03, I do not see the ethernet up/down issue anymore on the DRA821.

root@j7200-evm:~# uname -a
Linux j7200-evm 5.4.106-g023faefa70 #1 SMP PREEMPT Fri May 7 21:04:19 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

Regards,

--Gunter

Hi Karan and Vai,

looking at the DRA821 SOM schematics PROC105E6, it appears that the STB signal is connected to pad B17, which is register WKUP_PADCONFIG_42 at offset 0xA8.

This is clearly WKUP_GPIO0_58.

For the record. Hope this helps to modify the device tree files correctly.

We can just focus on MCU_MCAN0 for now.

Regards,

--Gunter

Hi Karan,

also I need to correct the statement about the pin 38 above. 

The device tree was touching WKUP_PADCONFIG_38 at offset 0x98. This affected WKUP_GPIO_54 as initially intended with the device tree patch.

The problem is that the schematics of the Common Processor Board incorrectly states that the MCU_MCAN0_STB pin is on WKUP_GPIO_54, while it is actually connected on WKUP_GPIO_58 (pad B17) as per the DRA821 SOM schematics.

Regards,

--Gunter

Hi Karan and Vai,

making the following changes:

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 1ae987c59..6e6117527 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -103,7 +103,7 @@
mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-pins-default {
pinctrl-single,pins = <
J721E_WKUP_IOPAD(0xc0, PIN_INPUT, 7) /* (B18) WKUP_GPIO0_0 */
- J721E_WKUP_IOPAD(0x98, PIN_INPUT, 7) /* (C9) MCU_MDIO0_MDIO.WKUP_GPIO0_54 */
+ J721E_WKUP_IOPAD(0xA8, PIN_INPUT, 7) /* (C9) MCU_MDIO0_MDIO.WKUP_GPIO0_58 */
>;
};

@@ -460,7 +460,7 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&mcu_mcan0_pins_default &mcu_mcan0_gpio_pins_default>;
- stb-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ stb-gpios = <&wkup_gpio0 58 GPIO_ACTIVE_HIGH>;
en-gpios = <&wkup_gpio0 0 GPIO_ACTIVE_HIGH>;
can-transceiver {
max-bitrate = <5000000>;

It appears the CAN gets probed correctly:

root@j7200-evm:~# dmesg |grep can
[ 7.105628] m_can_platform 40528000.can: m_can device registered (irq=13, version=32)
[ 7.480073] m_can_platform 40568000.can: m_can device registered (irq=15, version=32)

Regards,

--Gunter

Thanks, Karan.

The customer is in process of testing the MCU_MCAN0/1 now from Linux.

For the main domain MCAN from Linux with the GESI board, should I start a new thread? (and we can close this thread once the customer confirms it works)

Thanks,

--Gunter

Hi Gunter,

Thanks for creating a new thread for the MAIN MCAN instances https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1000106/dra821u-linux-enable-main-domain-mcan-ports-on-gesi-board 

As you said let us keep this for discussion on MCU MCANs. Will wait for the customers confirmation before closing this.

Regards,

Karan

Hello Gunter/Karan,

Thanks for looking into this. My pinmux conflicts seem to be rather different from the ones Gunter is seeing. I have conflicts between i2c0 and mcan1. Indeed if I see the device tree, offset 0xd4 is doubly committed, albeit one for IOPAD and other for WKUP_IOPAD.

Is it possible for you to attach your full k3-j7200-common-proc-board.dts, k3-j7200-mcu-wakeup.dtsi? I am using SDK 7.3 as my base.

Thanks

Vai

I can now confirm that the fixes above work! Thanks for all your help!

Hi Vai,

Vai Desai said:

Thanks for looking into this. My pinmux conflicts seem to be rather different from the ones Gunter is seeing. I have conflicts between i2c0 and mcan1. Indeed if I see the device tree, offset 0xd4 is doubly committed, albeit one for IOPAD and other for WKUP_IOPAD.

The IOPAD would mean that this is configuring the PADCONFIG registers and WKUP_IOPAD means it is programing the WKUP_PADCONFIG registers. So essentially these are different.

As communicated offline, you are able run without issues now. But can you please confirm what was causing the issue of conflicting pinmux?

Regards,

Karan

The problem was my patch for can0 wkup_iopad went into iopad section. This was conflicting with i2c0 which was using the same iopad pins. Once i moved my can1 device tree to wkup_iopad, those conflicts disappeared. And of course, also the can0 pinmux conflict fixes from above.

Thanks
Vai

Okay, got it! Thanks. The offset is the same and hence if you mix wkup_iopad and iopad, it will create an issue.

Please click on verify answer to close the issue.

Regards,

Karan