• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 5704 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3358: Overlays and CAN support for Beaglebone Black

Tracy Smith6
Intellectual 470 points

Part Number: AM3358

Tool/software: Linux

Need to enable DCAN1 and DCAN2 support for the BeagleBone Black. 

1) Are overlays supported by the latest Linux kernel supported by the TI dev?  

2) Where can I find documentations on enabling CAN1 and CAN2 for the BeagleBone Black on the latest kernel supported by TI dev board?

3) If overlays are no longer supported, documentation on enabling CAN without overlays?

4) Is the following information still reliable for the latest kernel and which release is the latest supported?

www.embedded-things.com/.../

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 41440 points

    Hi,

    Overlays are not supported on the TI SDK at the moment.  I can't get to the link you posted because believe it or not it is not currently passing muster on TI web filters.

    However, I can provide the info you need as I have had to recently enable a CAN cape on the BBB, though not two of them.  Are you making your own cape for a CAN interface or buying one?

    Attached is a document that can be used for enabling a cape or a board port for when it comes times to make a custom board. Please excuse the un-polished nature of the document as it is on it's way to become to become at least a wiki article.

    Attached is an example patch that can be used to enable CAN1. After looking at the example patch to enable DCAN0 on the BBB here is something you can start with for the DTS. I have not tried this, please let me know if it works:

    dcan1_pins_default: dcan1_pins_default {

       pinctrl-single,pins = <

           AM33XX_IOPAD(0x980, PIN_OUTPUT_PULLUP | MUX_MODE2) /* uart1_rxd.d_can1_tx */

           AM33XX_IOPAD(0x984, PIN_INPUT_PULLUP | MUX_MODE2) /* uart1_txd.d_can1_rx */

       >;

    };

    &dcan0 {

    status = "okay"; /* */

    pinctrl-names = "default";

    pinctrl-0 = <&dcan1_pins_default>;

    };

    Are you familiar with making changes to a DTS file, compiling it and adding it to the file system?

    Please post again if this did not answer your questions.

    Regards,

    Schuyler

    Enabling a DCAN interface on the Beagle Bone Black_20171030.docx

  • 0 in reply to Schuyler Patton
    TI__Mastermind 41440 points

    Here is the patch mentioned in previous post.....

    Fullscreen add_bbb_dcan1_patch.txt Download 
    diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 1230fd0..8016a46 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -86,6 +86,14 @@
 			AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a11.GPIO1_27 */
 		>;
 	};
+
+	dcan1_pins_default: dcan1_pins_default {
+		pinctrl-single,pins = <
+			AM33XX_IOPAD(0x980, PIN_OUTPUT_PULLUP | MUX_MODE2) /* uart1_rxd.d_can1_tx */
+			AM33XX_IOPAD(0x984, PIN_INPUT_PULLUP | MUX_MODE2) /* uart1_txd.d_can1_rx */
+		>;
+	};
+
 };
 
 &lcdc {
@@ -152,6 +160,13 @@
 	status = "okay";
 };
 
+&dcan1 {
+        status = "okay";    /* */
+        pinctrl-names = "default";
+        pinctrl-0 = <&dcan1_pins_default>;
+};
+
+
 / {
 	clk_mcasp0_fixed: clk_mcasp0_fixed {
 		#clock-cells = <0>;

  • 0 in reply to Schuyler Patton
    Intellectual 470 points



    Here is the latest CAN Support in the latest kernel tested as of last week. But since p9_xy use the P9 header, unable to use these changes.

    + cape-universal {
    + compatible = "gpio-of-helper";
    + status = "okay";
    + pinctrl-names = "default";
    + pinctrl-0 = <>;
    +
    + P9_19 {
    + gpio-name = "P9_19";
    + gpio = <&gpio0 13 0>;
    + input;
    + dir-changeable;
    + };
    +
    + P9_20 {
    + gpio-name = "P9_20";
    + gpio = <&gpio0 12 0>;
    + input;
    + dir-changeable;
    + };
    +
    + };


    Using the "latest" kernel builds from this last weekend.

    4.4.91-ti-r135/4.4.91-ti-rt-r135
    4.9.59-ti-r73/4.9.59-ti-rt-r73
    4.14.0-rc7-ti-r6

    4.13.10-bone3/4.13.10-bone-rt-r3

    Now support

    config-pin P9.19 can
    config-pin P9.20 can


    On startup:

    github.com/.../run_config-pin_during_startup.md

    you can do:

    #!/bin/bash

    config-pin P9.19 can
    config-pin P9.20 can

    config-pin P9.24 can
    config-pin P9.26 can

  • 0 in reply to Schuyler Patton
    Intellectual 470 points

    Hi Schuyler,

    I need to use these pins for the dts and for the u-boot pinmux.  Not using a CAPE, we are using the AM3358 for processing CAN and a USB device for the CAN cable. We will have two CANS. 

    CAN0 RX is D17
    CAN0 TX is D18
    CAN1 RX is E17
    CAN1 TX is E18

    In the case you provide above,

    1) which pins are 0x980 and 0x984 and how are you determining these values?

    2) how do these map to the BBB schematic pins? 

    3) How do I decode the iopad values for the pad names?

    4) Please also send any information making changes to a DTS file, compiling it and particularly adding it to the file system. 

    Using the TI dev. 

    The latest Linux kernel changes (v4.9.x-ti/v4.14.x-ti/v4.4.x-ti) that support CAN use the P9 header.  The P9_xy are on the P9 header and we don't have a P9 header. So, these changes won't help. For example:

    AM33XX_IOPAD(0x0978, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_20: uart1_ctsn.d_can0_tx */
    AM33XX_IOPAD(0x097c, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_19: uart1_rtsn.d_can0_rx */
    AM33XX_IOPAD(0x0980, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_26: uart1_rxd.dcan1_tx */
    AM33XX_IOPAD(0x0984, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_24: uart1_txd.dcan1_rx */

    thx,

    Tracy

  • 0 in reply to Tracy Smith6
    Intellectual 470 points
    This is similar to the USB/CAN device being used: www.kvaser.com/.../

    If you see any kernel related issue in using this device, such as kernel support required beyond the USB for instance, please let me know.
  • 0 in reply to Schuyler Patton
    Intellectual 470 points

    Hi Schuyler,

    I need to use these pins for the dts and for the u-boot pinmux. Not using a CAPE, we are using the AM3358 for processing CAN and a USB device for the CAN cable. We will have two CANS. This is similar to the USB/CAN device being used: www.kvaser.com/.../

    If you see any kernel related issue in using this device, such as kernel support required, please let me know.

    CAN0 RX is D17
    CAN0 TX is D18
    CAN1 RX is E17
    CAN1 TX is E18

    In the case you provide above for the TI dev,

    1) which pins are 0x980 and 0x984 and how are you determining these values?

    2) how do these map to the BBB schematic pins?

    3) How do I decode the iopad values for the pad names?

    4) Please also send any information making changes to a DTS file, compiling it and particularly adding it to the file system.

    The latest Linux kernel changes (v4.9.x-ti/v4.14.x-ti/v4.4.x-ti) that support CAN use the P9 header. The P9_xy are on the P9 header and we don't have a P9 header. So, these changes won't help. For example:

    AM33XX_IOPAD(0x0978, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_20: uart1_ctsn.d_can0_tx */
    AM33XX_IOPAD(0x097c, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_19: uart1_rtsn.d_can0_rx */
    AM33XX_IOPAD(0x0980, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_26: uart1_rxd.dcan1_tx */
    AM33XX_IOPAD(0x0984, PIN_INPUT_PULLUP | MUX_MODE2) /* P9_24: uart1_txd.dcan1_rx */

    thx,

    Tracy

  • 0 in reply to Tracy Smith6
    Intellectual 470 points

    Also, the pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don't see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18),

    1. Did I miss the names for these pins in u-boot?

    2. If u-boot does not support these pins, should they be added to u-boot, and/or added to the kernel to support these pins?

    Need these pins to support USB/CAN device on a custom BBB since there is no P9 expander and because of pin conflicts otherwise. Need to pinmux these to use the USB/CAN device ( Lawicel).

    An update.   In u-boot/board/ti/am335x I do see the following. So, the pad name for I2C_DATA is uart1_ctsn for D18.  For pad name uart1_rtsn it is pin D17.  So this will give the DCAN0_TX/RX.

    static struct module_pin_mux i2c2_pin_mux[] = {
            {OFFSET(uart1_ctsn), (MODE(3) | RXACTIVE |
                            PULLUP_EN | PULLUDEN | SLEWCTRL)},      /* I2C_DATA */
            {OFFSET(uart1_rtsn), (MODE(3) | RXACTIVE |
                            PULLUP_EN | PULLUDEN | SLEWCTRL)},      /* I2C_SCLK */
            {-1},
    };

    Now looking in u-boot/board/ti/am335x for E17/E18 for DCAN1_TX/RX.  TI and Robert Nelson could use E17/E18 for CAN1 and use the P9 expansion header for CAN2/3 if needed or could avoid disabling the I2C for the eeprom.

  • 0 in reply to Schuyler Patton
    Intellectual 470 points

    We routed D17/D18 and E17/E18 to CAN1/2 TX/RX.  Needed to find the hex values for the dts above.  The definition of the pins is what I was looking for and all the information has been very helpful.

    https://dev.ti.com/pinmux/app.html#/default

    mydcan1_pins_default: mydcan1_pins_default {
        pinctrl-single,pins = <
            0x16c ( PIN_INPUT | MUX_MODE2 ) /* (E17) uart0_rtsn.dcan1_rx */
            0x168 ( PIN_OUTPUT | MUX_MODE2 ) /* (E18) uart0_ctsn.dcan1_tx */
        >;
    };

    mydcan2_pins_default: mydcan2_pins_default {
        pinctrl-single,pins = <
           0x17c ( PIN_INPUT | MUX_MODE2 ) /* (D17) uart1_rtsn.dcan0_rx */
            0x178 ( PIN_OUTPUT | MUX_MODE2 ) /* (D18) uart1_ctsn.dcan0_tx */
        >;
    };

  • 0 in reply to Tracy Smith6
    TI__Mastermind 41440 points
    Hi

    Thanks for posting the link that you were using the pin mux tool. I was a little confused on the pin offset in the pin mux structures. You found a bug in the tool that we need to track down and correct. The reason is the address offset of 17c for D17 is incorrect to work with the latest TI SDK pin mux.

    Also the pins according to the BBB schematic do not show processor pins E17/18 hooked up completely.

    Based on your earlier question here is how I think you should set up the interfaces, hopefully I have broken down the pin references:

    Parsing the first line below, the first is the pin coordinates from the datasheet, 96Ch is the offset of the control module register for this pin configuration, the table in the AM335x technical reference manual (TRM), the data sheet pin name and pin mux mode, the P9 signal name in the BBB schematic and the pin number on the connector.

    D18 96Ch conf_uart1_ctsn Table Section 9-10 uart0_ctsn.d_can0_tx p9 – I2C2_SDA pin 20
    D17 968h conf_uart1_rtsn Table Section 9-10 uart0_rtsn.d_can0_rx p9 – I2C2_SCL pin 19
    D16 980h conf_uart1_rxd Table Section 9-10 uart1_rxd.d_can1_tx p9 – UART1_RXD pin 28
    D15 984h conf_uart1_txd Table Section 9-10 uart1_txn.d_can1_rx p9 – UART1_TXD pin 26

    This link will show how to compile a device tree source file:
    processors.wiki.ti.com/.../Linux_Kernel_Users_Guide

    Please let me know if that helps.

    Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    Intellectual 470 points

    Hi Schuyler,

    here is our routing for our custom BBB.  Your recommendation above assumes the BBB doesn't fully route E17/E18, but in our case they are routing E17/E18 to CAN1.

    Are you saying we should use D16/D17 for CAN1 instead of E17/E18 even though we routed E17/E18 to CAN1? If so, please explain why it is recommended?

    Also, it looks like there is a macro in the header files that adds a 0x800 offset to the address in the dts file so 0x16C would become 0x96Ch. So, is this macro fixing the offset because of the offset issue within the TI pinmuxing tool? If so, once fixed will the macro need to be removed for any future boards once the offsets are fixed in the pinmux tool? 

    thx, Tracy

  • 0 in reply to Tracy Smith6
    TI__Mastermind 41440 points
    Hi Tracy,
    I was concerned that the pin mux tool output would not work with the DTC compiler, it does if you have not already tried it out. Both the tool output and the macro based pin definitions work. The macro subtracts the offset of the start of the pin mux configuration registers. The macro was added for readability according to the commit message. The tool output follows the pinctrl binding document in the kernel Documentation directory.

    I was operating under the impression that you were working directly with the BBB and not a custom board design and is that I locked onto the D16/D17. It is ok to use the E17/E18 pins.

    Regards,
    Schuyler