Overlays and 4.14 Linux kernel for CAN

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

  1. Are overlays supported by the 4.14 Linux kernel?

  2. Where can I find documentation on enabling CAN1 and CAN2 for the BeagleBone Black for the 4.x kernel?

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

http://zewaren.net/site/node/152

  1. Does Linux kernel 4.14 release support BBB WiFi?

  2. Is the following information still reliable for the 4.x kernel and which release is the latest supported release for BeagleBone black with WiFi, is it 4.14 stable?

http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/

http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/overlay-notes.txt

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

1) Are overlays supported by the 4.14 Linux kernel?

You can use "U-Boot" overlays:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

2) Where can I find documentation on enabling CAN1 and CAN2 for the
BeagleBone Black for the 4.x kernel?

make sure to update "bb-cape-overlays" package and that you are using
U-Boot overlays..

can1:

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

for can0:

I'm testing this right now:

https://github.com/RobertCNelson/dtb-rebuilder/commit/941d12d5328a268e6070fcd84da57645f035b1b4

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

(v4.9.x-ti will be first, followed by v4.14.x-ti/v4.4.x-ti)

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

http://zewaren.net/site/node/152

4) Does Linux kernel 4.14 release support BBB WiFi?

yeap,

5) Is the following information still reliable for the 4.x kernel and which
release is the latest supported release for BeagleBone black with WiFi, is
it 4.14 stable?

nah, use config-pin

Regards,

Thanks Robert this is great! Please let me know how it goes. I need to pinmux different pins D18/D17 and E17/E18 for CAN1 and CAN2. The CAN pins are used for UART or other. What is the pinmuxing file that should be modified for this?

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

I need to have everything in a build for a release and not only enabling CAN on an existing boot. So, any script based mods pulled from repos on a booted system, I need to add to the appropriate files for that release. The pinmux in particular for the kernel. What is equivalent to the uboot pinmux file for the 4.14 kernel?

thx,
Tracy

Thanks Robert this is great! Please let me know how it goes. I need to
pinmux different pins D18/D17 and E17/E18 for CAN1 and CAN2. The CAN pins
are used for UART or other. What is the pinmuxing file that should be
modified for this?

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

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:

https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/doc/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

I need to have everything in a build for a release and not only enabling CAN
on an existing boot. So, any script based mods pulled from repos on a
booted system, I need to add to the appropriate files for that release. The
pinmux in particular for the kernel. What is equivalent to the uboot pinmux
file for the 4.14 kernel?

So the other option, just hard code the can nodes, using dtb-rebuilder:

https://github.com/RobertCNelson/dtb-rebuilder

(pick a branch that matches your kernel)

Regards,

ok that works I’ll use the dtb-rebuilder.

I’m comparing against the BBB schematic for the pin numbers and need to understand how they are mapping to the pinmux pins in src/arm/am335x-bone-common.dtsi.

For example, which BBB schematic pins are P9.19 and P2.20 on the BBB schematic since I need to check for any conflicts on our board for pinmuxing. I don’t see a gpio9-19 or a gpio9-20 on the BBB rev-c schematic. I’m looking at document 450-5500-001 Rev C March 21, 2014.

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

  • cape-universal {

  • compatible = “gpio-of-helper”;

  • status = “okay”;

  • pinctrl-names = “default”;

  • pinctrl-0 = <>;

ok that works I'll use the dtb-rebuilder.

I'm comparing against the BBB schematic for the pin numbers and need to
understand how they are mapping to the pinmux pins in
src/arm/am335x-bone-common.dtsi.

For example, which BBB schematic pins are P9.19 and P2.20 on the BBB
schematic since I need to check for any conflicts on our board for
pinmuxing. I don't see a gpio9-19 or a gpio9-20 on the BBB rev-c schematic.
I'm looking at document 450-5500-001 Rev C March 21, 2014.

P9.19/P9.20 is an i2c bus by default, so you'll have to carve it out like:

https://github.com/RobertCNelson/linux-dev/blob/master/patches/soc/ti/uboot/0002-am335x-bone-common-config-pin-carve-out-P9.19-P9.20.patch

- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins = <
- AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_ctsn.i2c2_sda
*/
- AM33XX_IOPAD(0x97c, PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_rtsn.i2c2_scl
*/
- >;
- };
+// i2c2_pins: pinmux_i2c2_pins {
+// pinctrl-single,pins = <
+// AM33XX_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE3) /*
uart1_ctsn.i2c2_sda */
+// AM33XX_IOPAD(0x97c, PIN_INPUT_PULLUP | MUX_MODE3) /*
uart1_rtsn.i2c2_scl */
+// >;
+// };
&i2c2 {
pinctrl-names = "default";
- pinctrl-0 = <&i2c2_pins>;
+ //pinctrl-0 = <&i2c2_pins>;
+ pinctrl-0 = <>;

Otherwise the can0/1 is just:

&am33xx_pinmux {
dcan0_pins: pinmux_dcan0_pins {
pinctrl-single,pins = <
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 */

;

};

dcan1_pins: pinmux_dcan1_pins {
pinctrl-single,pins = <
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 */

;

};
};

&dcan0 {
pinctrl-names = "default";
pinctrl-0 = <&dcan0_pins>;
status = "okay";
};

&dcan1 {
pinctrl-names = "default";
pinctrl-0 = <&dcan1_pins>;
status = "okay";
};

Regards,

I see. Thanks Robert. The P9 is the BBB expansion header? If so, we are not using an expansion header and we don’t have P9 correct? So, we need to pinmux the following:

CAN0 RX is D17

CAN0 TX is D18

CAN1 RX is E17

CAN1 TX is E18

per our pinmux file using the TI PinMux tool to avoid conflicts.

Correct, P9_xy, are on the P9 header,

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 */

Sorry, you'll have to decode the iopad values for the pad names, i hardly
look a the pad names..

Regards,

We are using a USB device for the CAN so we are using the AM3358 and
no CAPE and we are not using the P9 header. The device is an OEM
version and similar to the kvaser USB/CAN connectors.

https://www.kvaser.com/product/kvaser-usb-hs-ii-hsls/

1) Do you see any kernel issues using this configuration once we have
set up the device tree for CAN0/CAN1 pins below?

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

2) Can we access the E17/E18 or D17/D18 through the P9 header?

3) Is there a particular reason to use the P9 header instead of USB
for CAN (speed not a concern for us)?

4) Any additional kernel support required for using CAN over USB?
https://www.kvaser.com/product/kvaser-usb-hs-ii-hsls/

Hi Robert,

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 this pins for u-boot?

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

thx,
Tracy