Overlays and 4.14 Linux kernel for CAN

[Tracy Smith]

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

4) Does Linux kernel 4.14 release support BBB WiFi?

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?

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

[Robert Nelson]

On Fri, Oct 27, 2017 at 10:59 AM, Tracy Smith <tlsmi...@gmail.com> wrote:
> 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,

--
Robert Nelson
https://rcn-ee.com/

[Tracy Smith]

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

[Robert Nelson]

On Mon, Oct 30, 2017 at 3:39 PM, Tracy Smith <tlsmi...@gmail.com> wrote:
> 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)

[Tracy Smith]

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 = <>;

+

+ 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;

+ };

+

+ };

[Robert Nelson]

On Mon, Oct 30, 2017 at 4:37 PM, Tracy Smith <tlsmi...@gmail.com> wrote:

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,

[Tracy Smith]

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.

--

Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), please immediately notify the sender and delete this e-mail message.

[Robert Nelson]

On Mon, Oct 30, 2017 at 5:39 PM, Tracy Smith <tlsmi...@gmail.com> wrote:

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,

[Tracy Smith]

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/

[Tracy Smith]

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