DRA821U: Linux: Multiple MCAN CAN-FD peripheral support

Part Number: DRA821U
Other Parts Discussed in Thread: DRA829, TDA4VM,

Hi,

looking through the PSDKLA documentation, I cannot find MCAN support, just DCAN support under Linux kernel drivers.

For a customer application, we need multiple MCAN peripherals supported, let's assume from Main Domain. We are using the DRA821 SOM with Common Processor Board and GESI board.

[] Could you send me instructions on how to enable the MCAN driver in Linux?

[] Could you send me instructions on how to enable multiple GESI MCAN ports in the device tree?

Thanks!

--Gunter

  • 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

  • Hi Gunter,

    Please take reference from the patches attached to test CAN on Linux on DRA821. Please note, I haven't been able to test this due till now but this should work.

    Patches on SDK7.3:

     0001-arm-dts-ti-k3-j7200-mcu-wakeup-Add-support-for-mcu_m.patch

    0002-arm-dts-ti-k3-j7200-common-proc-board-Add-support-fo.patch

    Use instructions from FAQ here to test: https://e2e.ti.com/support/processors/f/processors-forum/922168/faq-tda4vm-how-can-i-use-can-on-linux 

    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

  • Hi Gunter,

    Thanks for confirming the Schematics bug, I will file a bug to get it updated.

    Meanwhile attaching the updated set of patches, this only has the pinmux change.

    vcl_can_patches.zip

    Thanks for confirming that it works, use the above set of patches.

    Regards,

    Karan

  • 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,

    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