from:"Tracy Smith"

[beagleboard] Overlays and 4.14 Linux kernel for CAN

2017-10-27 Thread 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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2a9a3a73-e5e5-46e2-b198-15ffd95d5989%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

2017-10-30 Thread 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

On Friday, October 27, 2017 at 12:57:09 PM UTC-5, RobertCNelson wrote:
>
> On Fri, Oct 27, 2017 at 10:59 AM, Tracy Smith  > 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/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/269dec7e-e95c-46aa-a1de-18dbcd471f42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

2017-10-30 Thread 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; 
+ }; 
+ 
+ };


On Monday, October 30, 2017 at 4:31:38 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Oct 30, 2017 at 3:39 PM, Tracy Smith  > 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) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e7c35d23-215c-4ec4-a5a0-6477732a9353%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

2017-10-30 Thread 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.

On Mon, Oct 30, 2017 at 4:54 PM, Robert Nelson 
wrote:

>
>
> On Mon, Oct 30, 2017 at 4:37 PM, Tracy Smith 
> 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,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>



-- 
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.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAChUvXN%3DOhrJ-HaBd%3D9%3De6dNpuRyKc7%2BtngdqPCgHum-7s%3D1iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

2017-10-31 Thread 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/

On Mon, Oct 30, 2017 at 6:58 PM, Robert Nelson  wrote:
>
>
> On Mon, Oct 30, 2017 at 5:39 PM, Tracy Smith  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,
>
> --
> Robert Nelson
> https://rcn-ee.com/



-- 
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.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAChUvXMXKN74sWAEn3R7rO3Rc%2BqXZ9nx8nGjJHJUvrms337s1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Overlays and 4.14 Linux kernel for CAN

2017-10-31 Thread 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

On Friday, October 27, 2017 at 10:59:16 AM UTC-5, Tracy Smith wrote:
>
> 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>
>
>
> http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/overlay-notes.txt
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4aeef0d8-713d-4091-980b-1cbf52bb5c38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] u-boot support for pins

2017-10-31 Thread Tracy Smith

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. Need to pinmux 
these for the USB/CAN from Lawicel.

thx,
Tracy

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cbfa210e-1ccd-4983-8599-83960631f01e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB- DCAN1 problems using latest debian image

2017-10-31 Thread Tracy Smith

Hi John,

I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have 
a custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2.  

The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for 
the BBB 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?

Should these pins be pinmuxed in both uboot and the  kernel, or only in the 
kernel dts?  Checking now to see if the kernel has support for these pins.

thx, Tracy

On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote:
>
> Hi,
>
> I have been trying to build a proof of concept system using two beaglebone 
> black units with there DCAN1 (pins P9_24 and P9_26) and two can 
> transcievers TI SN65HVD251P.
> The can transceivers are powered from the same 5V bench supply as both of 
> the beaglebone blacks. the canh and canl pins are terminated at both ends 
> by 120R resistors to ensure the 60R bus impedence. 
>
> I was following the instructions in other posts about updating to the 
> latest debian version and then upgrading the kernel to 3.14. This i have 
> done.
> uname -a
> Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 
> 2015 armv7l GNU/Linux
>
> I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt
>
> I have also installed the canbus tools within the image so i can attempt a 
> cangen can0 and candump can0.
>
> On system boot i am doing the following:
>
> modprobe can
> modprobe can-dev
> modprobe can-raw
>
> ip link set can0 type can bitrate 125000 triple-sampling on
> ifconfig can0 up
>
> however if i use candump can0 and cangen can0 within two seperate putty 
> sessions i dont see anything. 
>
> If I create a vcan bus i do see the messages in loopback.
> sudo modprobe vcan
> sudo ip link add dev vcan0 type vcan
>  sudo ifconfig vcan0 up
>
> Previously I was using an older debian image and found that when i ran 
> cangen can0 that the buffer would give me an error that it was full. 
> however now with the latest image i am not getting the bufer full message 
> but still not seeing anything on the candump. What should i expect to see 
> here?
>
> Can anyone see where I have gone wrong or a step i am missing?
>
> Thanks in advance.
>
> Mark
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e6297438-0999-4320-916e-f41d74671533%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: u-boot support for pins

2017-10-31 Thread Tracy Smith



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 for u-boot.


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.  One 
could use E17/E18 for CAN1 instead of the P9 expansion header.

On Tuesday, October 31, 2017 at 5:37:43 PM UTC-5, Tracy Smith wrote:
>
> 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. Need to pinmux 
> these for the USB/CAN from Lawicel.
>
> thx,
> Tracy
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f1e6ec6e-97c4-4d27-ac1f-4fd4fa881efc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image

2017-11-01 Thread Tracy Smith

Hi John, 

Do you see support for both CAN0 and CAN1?  Need both and our pins for CAN1 are 
E17 and E18 in the TI pinmux tool.  Found the pad names and pins in uboot 
pinmux for CAN0 after this post.  Haven’t found pad names associated with 
E17/E18 yet in uboot pinmux. Will look at the kernel dts today.  

My question I guess will CAN1 be available when plugging in the CANUSB and 
where do you see CAN1 indicated?  If supported, it will appear as /dev/ttyUSB1? 
 Or, as a different device on the BBB?  Eventually may need as many as four 
CAN0-3.

Thx, Tracy

> On Oct 31, 2017, at 8:00 PM, John Dammeyer  wrote:
> 
> The CANUSB from Lawicel is a standard USB device that looks like a serial 
> port since it can use the FTDI driver.
>  
> On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a 
> /dev/ttyUSB0 device.
> I installed putty and connected to /dev/ttyUSB0
> In the terminal window
> V with a CR returns
> V1011
> An S5 sets 250kbps
> An O opens the port.
> t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88
> With nothing connected to the CANUSB the red LED goes on.  (or if bitrate is 
> wrong).
> A C closes the port.
> An F prints the error flags and shuts off the red led.
>  
> It’s a good idea to have auto line feed set in putty so that each received 
> message is on a new line.
> John Dammeyer
>  
>  
>  
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Tracy Smith
> Sent: October-31-17 3:42 PM
> To: BeagleBoard
> Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
>  
> Hi John,
> 
> I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a 
> custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2.  
> 
> The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the 
> BBB 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?
> 
> Should these pins be pinmuxed in both uboot and the  kernel, or only in the 
> kernel dts?  Checking now to see if the kernel has support for these pins.
> 
> thx, Tracy
> 
> On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote:
> Hi,
>  
> I have been trying to build a proof of concept system using two beaglebone 
> black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers 
> TI SN65HVD251P.
> The can transceivers are powered from the same 5V bench supply as both of the 
> beaglebone blacks. the canh and canl pins are terminated at both ends by 120R 
> resistors to ensure the 60R bus impedence. 
>  
> I was following the instructions in other posts about updating to the latest 
> debian version and then upgrading the kernel to 3.14. This i have done.
> uname -a
> Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 
> 2015 armv7l GNU/Linux
>  
> I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt
>  
> I have also installed the canbus tools within the image so i can attempt a 
> cangen can0 and candump can0.
>  
> On system boot i am doing the following:
>  
> modprobe can
> modprobe can-dev
> modprobe can-raw
>  
> ip link set can0 type can bitrate 125000 triple-sampling on
> ifconfig can0 up
>  
> however if i use candump can0 and cangen can0 within two seperate putty 
> sessions i dont see anything. 
>  
> If I create a vcan bus i do see the messages in loopback.
> sudo modprobe vcan
> sudo ip link add dev vcan0 type vcan
>  sudo ifconfig vcan0 up
>  
> Previously I was using an older debian image and found that when i ran cangen 
> can0 that the buffer would give me an error that it was full. however now 
> with the latest image i am not getting the bufer full message but still not 
> seeing anything on the candump. What should i expect to see here?
>  
> Can anyone see where I have gone wrong or a step i am missing?
>  
> Thanks in advance.
>  
> Mark
>  
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/_9u1B6ZkgCU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://g

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

Hi William,

Using the TI pinmux tool it provides two pins associated with CAN1. One for TX 
and one for RX.  I just need to use these two pins for the uboot overlays 
instead of the I2C P9 extension header supported by the most recent kernel 
releases. On our custom BBB we don’t have a P9 and instead we use test point 
pins for CAN1. CAN0 is no longer a concern since I have the pad names 
associated with the pins I need.

I need to know the pad name or how to create the pad names for these two pins 
the pinmux tool associates with CAN1, so I can use these for the u-boot pinmux 
and the kernel device tree.  I agree this is not difficult when you have the 
pad names and the pins available. Simply copy, paste, and modify the dts and 
pinmux file as needed.

Thx, Tracy

Sent from my iPad

> On Oct 31, 2017, at 7:55 PM, William Hermans  wrote:
> 
> SO what is it that you're trying to do ? I've read your posts, but am still 
> mystified. Just sayin' . . . I've been working with this hardware for around 
> 5 years now,  have written many device tree overlays for various hardware 
> configurations. Including GPIO, I2C, UART, CAN, SPI, etc.
> 
> I'm willing to give you some guidance, but need to understand what it is 
> you're trying to do . . .
> 
> I2C really isn't that hard to get working. Nor is most of it.
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CALHSORrdO87s1J7uKrJ%2BEvRKQRmKhahZBq%3DmtK1ktk4sChsbkA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/61C6671A-8967-48F3-A46A-A8F521690382%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image

2017-11-01 Thread Tracy Smith

Hi John,

Both CANS are working on BBB even though Robert Nelson is implementing these on 
the P9 expansion header?

So what indicates the second CAN is working fine on BBB?  What do I look for to 
see the second CAN is working properly?

If this is the case, I just need to validate both are working and save myself 
time. We only saw the first CAN working.

Thx, Tracy

> On Nov 1, 2017, at 10:33 AM, John Dammeyer  wrote:
> 
> CAN1 and CAN2 are available when you aren’t using any other cape and I think 
> eiher HDMI or perhaps it’s the LCD interface.  It’s been a while.  There is 
> no relationship between /dev/ttyUSB0 and the CAN devices.  One requires a CAN 
> driver to function while the other is purely a serial port like a UART.
>  
> To get 5 CAN ports I chose the Freescale 9S12 series.  I think ST Micro also 
> makes an ARM compatible processor with 4 CAN ports.  There aren’t a lot 
> around.
>  
> If you want higher speed access along with message interrupts than what you 
> can get with USB FTDI based CAN connections your alternative approach will be 
> to add Microchip MCP2515s on board and use the SPI bus interface.  With 3 
> select lines to a 3:8 mux you can select one of 4 CAN devices, and wire-OR 
> the interrupts.  You just have to poll which one caused the interrupt.  I 
> believe there is a driver for the MCP2515 already in the Beagle CAN library.
>  
> Alternatively, since you are already building a cape that has CAN drivers on 
> it and you now you want at least 2 more CAN devices it may be easier to use a 
> second processor that has two CAN ports.  Write the firmware to look like an 
> SPI based MCP2515 and you can use the stock Beagle CAN driver for it.
>  
> In fact, use either the ST Micro ARM and make all the CAN ports on it appear 
> as if they were MCP2515s and that then frees up your other pins on the Beagle.
>  
> John
>  
>  
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Tracy Smith
> Sent: November-01-17 2:51 AM
> To: beagleboard@googlegroups.com
> Subject: Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
>  
> Hi John, 
>  
> Do you see support for both CAN0 and CAN1?  Need both and our pins for CAN1 
> are E17 and E18 in the TI pinmux tool.  Found the pad names and pins in uboot 
> pinmux for CAN0 after this post.  Haven’t found pad names associated with 
> E17/E18 yet in uboot pinmux. Will look at the kernel dts today.  
>  
> My question I guess will CAN1 be available when plugging in the CANUSB and 
> where do you see CAN1 indicated?  If supported, it will appear as 
> /dev/ttyUSB1?  Or, as a different device on the BBB?  Eventually may need as 
> many as four CAN0-3.
>  
> Thx, Tracy
> 
> On Oct 31, 2017, at 8:00 PM, John Dammeyer  wrote:
> 
> The CANUSB from Lawicel is a standard USB device that looks like a serial 
> port since it can use the FTDI driver.
>  
> On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a 
> /dev/ttyUSB0 device.
> I installed putty and connected to /dev/ttyUSB0
> In the terminal window
> V with a CR returns
> V1011
> An S5 sets 250kbps
> An O opens the port.
> t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88
> With nothing connected to the CANUSB the red LED goes on.  (or if bitrate is 
> wrong).
> A C closes the port.
> An F prints the error flags and shuts off the red led.
>  
> It’s a good idea to have auto line feed set in putty so that each received 
> message is on a new line.
> John Dammeyer
>  
>  
>  
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Tracy Smith
> Sent: October-31-17 3:42 PM
> To: BeagleBoard
> Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image
>  
> Hi John,
> 
> I'm attempting to enable CAN support for a USB/CAN from a Lawicel. We have a 
> custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2.  
> 
> The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the 
> BBB 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?
> 
> Should these pins be pinmuxed in both uboot and the  kernel, or only in the 
> kernel dts?  Checking now to see if the kernel has support for these pins.
> 
> thx, Tracy
> 
> On Wednesday, April 8, 2015 at 8:20:29 AM UTC-5, Mark Irwin wrote:
> Hi,
>  
> I have been trying to bui

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

We have no P9expansion header.  I’ve already discussed this with Robert Nelson. 
 We are using the AM3358 pins I sent previously.  Any can using the P9and this 
overlay will not work for our custom board.

Sent from my iPad

> On Nov 1, 2017, at 12:03 PM, William Hermans  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 5:44 AM, Tracy Smith  wrote:
>> Hi William,
>> 
>> Thanks for the email and here is what I’m trying to do.
>> 
>> The CANUSB from Lawicel is a standard USB device that looks like a serial 
>> port since it can use the FTDI driver.
>>  
>> On the MachineKit Debian Beagle the CANUSB is a dev/ttyUSB0 device.
>> 
>> On our custom BeagleBone Black, we want both CAN0 and CAN1 accessible USB 
>> devices.  We don’t want to have to add a P9 expansion header on the custom 
>> board for I2C and we have specific pins E17 and E18 we want to use that are 
>> designated as possible CAN1 pins on the BeagleBone Black schematic. 
>> 
>> These two pins for CAN1 are tstpt1 pin E17 and TP9 pin E18.  Just need to 
>> see if there is a pad name associated with these pins so I can use them for 
>> the pinmux file and device tree to make CAN1 available as a USB device for 
>> uboot and the kernel.  This is what I need.
>> 
>> Looking through the pinmux files for any pad names associated with these two 
>> pins.  
>> 
>> Thx, Tracy
>> 
> Just use the file I sent you, no worries about anything. If you NEED to put 
> it all into one large overlay file, you can pretty much just copy paste 
> what's in that file into your existing overlay. WIth some caveats of course. 
> You'll need to make sure the file is organized correctly.  
> 
> Personally, I'd just leave the file as is, and load it standalone.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/94E21FCA-DC0B-4F6A-8EC1-BDE937A5A1EF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

E17 and E18 we want to use that are designated as possible CAN1 pins on the 
BeagleBone Black schematic. 

Not using a different overlay, using the existing 4.14 kernel and 2017 I boot 
that Robert Nelson suggests using for the BBB. But we need to pinmux for E17 
and E18 because the TI pinmuxing tool finds no conflict with these two pins on 
our custom board. I’ll go back and check the CAN1 but prior to Roberts changes 
last week that did not use the P9 expansion header, the unit pinmux used 
different pins CAN1 I believe.  With the P9 expansion header, can’t use Roberts 
overlay because there is no P9 expansion header on our BBB board. I’ll go back 
look at the pins for CAN1 prior to then P9 overlay changes from last week by 
Robert.

This is just basic pinmuxing.  And looking for E17 and E18 pons since these are 
supposed to support CAN1 on the AM33xx.

Thx



Sent from my iPhone

> On Nov 1, 2017, at 12:21 PM, William Hermans  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 10:17 AM, William Hermans  wrote:
>> 
>> 
>>> On Wed, Nov 1, 2017 at 10:12 AM, William Hermans  wrote:
>>> 
>>> 
>>>> On Wed, Nov 1, 2017 at 10:05 AM, Tracy Smith  wrote:
>>>> We have no P9expansion header.  I’ve already discussed this with Robert 
>>>> Nelson.  We are using the AM3358 pins I sent previously.  Any can using 
>>>> the P9and this overlay will not work for our custom board.
>>> 
>>> Ok, good, that doesn't make a bit of difference at all. Those pin names in 
>>> the overlay are just variables used by the file, and initially by cape 
>>> manager. cape manager translates those variable names into addresses when 
>>> the overlay file is compiled. 
>>> 
>>> Passed that, the software that is provided could stll use the Px header 
>>> designation for the pins, and it'll still work fine if you're using 
>>> something like universal IO + config-pin, so long as you all have not done 
>>> something drastically different in your layout. I do recall that some 
>>> devices can be done using multiple pin configurations, and one in fact is 
>>> still like that with the beaglebone design as is.
>>> 
>>> Anyway, I do not remember if CAN1 has the potential to be on different pins 
>>> or not. Out of the processor. But working with the file I sent you a link 
>>> to all that can easily be changed.
>> 
>> Well technically, I'm not 100% positive on this. There could be hooks, etc 
>> I'm not aware of, and I have not done this hands on personally. But so long 
>> as you're using the same pins the bealgebone is using. It should work. 
>> 
>> Are you, or are you not using he same pins as the beaglebone for CAN1 ?
> 
> Another thing I did not consider is that it sounds like you could be using a 
> completely different board file overlay for your hardware, at which point all 
> bets are off. 
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/09758031-8B06-438A-B9F7-304F33BEBA98%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

These comments were a reply to Robert,!but threads are getting confused a bit 
for everyone especially for me.

Let me look at this more and see if I can find the pinmux pins I need in i-boot 
and the kernel. Even if they don’t exist in u-boot, they should in the kernel. 
Then I can do as Robert indicates, change the pinmux U-Boot file and dts.

If I go into any more detail, it’s going to take too much time and I’m already 
behind on this.  Robert understands the concerns and what I need. I simply need 
to pinmux pins E18 and E19.


> On Nov 1, 2017, at 1:09 PM, William Hermans  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 11:01 AM, Tracy Smith  wrote:
>> Ok look this custom board is based on the BeagleBone Black. For all intense 
>> and purposes it is the BBB. The pins for the AM3358 are the same. The 
>> primary difference is no P9 expansion header. What you are suggesting below 
>> is exactly what I’m doing and why I have the questions I do because your CAN 
>> support will not work on our custom BeagleBone Black.
>> 
>> Customers will use the BBB as a reference platform and will actually have to 
>> do pinmuxing. When I do mention custom board, you do ignore me. But you 
>> shouldn’t because not all companies that use the BBB as a reference platform 
>> will use the P9 expansion and they will want to have CAN support in the 
>> kernel even without the P9 expansion header. You don’t have to use the P9 
>> and the overlay being used to support CAN0 and CAN1
>> 
>> You seem to be limiting CAN support to those using the P9 expansion header?  
>> Why is that? Does it allow for four or more CANS?  
>> 
>> Really appreciate the assistance and it has been and continues to be 
>> extremely helpful. 
>> 
>> What limitations or constraints are causing you to have to use the P9 
>> expansion header for CAN?  Knowing this help justify adding an expansion 
>> header to the design. 
>> 
>> I need to look closer at the overlay. But knowing these constraints could 
>> justify adding the P9 expansion header to our custom BBB board.
>> 
>> Thx, Tracy
> 
> First, I am not affiliated with beagleboard.org, cicuitco or any other 
> organization related directly to the beaglebone, or beagleboard products. Or 
> anyone who sells said products. I am just your average community member, 
> whose been using the beaglebone products since it's release date
> 
> Second, I never said I was ignoring anyone.
> 
> Third, you're delving into territory that myself, and most others have not 
> gone into. So if someone does say they're ignoring you, it could very well be 
> that they have not done what you're doing, and do not want to give you 
> incorrect information.
> 
> Lastly, be more verbose with your information. Just saying "wont work for us" 
> doesn't tell us what the underlying problem is, or how to help you solve your 
> issue.
> 
> So . .. tell us EXACTLY what you've done, and EXACTLY the errors your 
> experiencing. Then perhaps, if you're verbose enough, someone on this list 
> can help you.
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/DE388E17-0772-445D-92F5-2B6F87DF0734%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

The signals are all routed just need to pinmux E18 and E19 which are the same 
for the BBB.

Sent from my iPhone

> On Nov 1, 2017, at 1:19 PM, Robert Nelson  wrote:
> 
>> On Wed, Nov 1, 2017 at 1:14 PM, Tracy Smith  wrote:
>> E17 and E18 we want to use that are designated as possible CAN1 pins on the
>> BeagleBone Black schematic.
>> 
>> Not using a different overlay, using the existing 4.14 kernel and 2017 I
>> boot that Robert Nelson suggests using for the BBB. But we need to pinmux
>> for E17 and E18 because the TI pinmuxing tool finds no conflict with these
>> two pins on our custom board. I’ll go back and check the CAN1 but prior to
>> Roberts changes last week that did not use the P9 expansion header, the unit
>> pinmux used different pins CAN1 I believe.  With the P9 expansion header,
>> can’t use Roberts overlay because there is no P9 expansion header on our BBB
>> board. I’ll go back look at the pins for CAN1 prior to then P9 overlay
>> changes from last week by Robert.
> 
> What i suggested, assumed you were using a BBB.  Thus since you have a
> custom board, it's all null and void..
> 
> Use TI's pinmux tool and properly route your can signals.
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4780F9F7-D160-4C49-9715-4AA47E65FFF7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

The need to use E18 and E19 For CAN1 comes from the TI pinmux tool.

Sent from my iPhone

> On Nov 1, 2017, at 1:19 PM, Robert Nelson  wrote:
> 
>> On Wed, Nov 1, 2017 at 1:14 PM, Tracy Smith  wrote:
>> E17 and E18 we want to use that are designated as possible CAN1 pins on the
>> BeagleBone Black schematic.
>> 
>> Not using a different overlay, using the existing 4.14 kernel and 2017 I
>> boot that Robert Nelson suggests using for the BBB. But we need to pinmux
>> for E17 and E18 because the TI pinmuxing tool finds no conflict with these
>> two pins on our custom board. I’ll go back and check the CAN1 but prior to
>> Roberts changes last week that did not use the P9 expansion header, the unit
>> pinmux used different pins CAN1 I believe.  With the P9 expansion header,
>> can’t use Roberts overlay because there is no P9 expansion header on our BBB
>> board. I’ll go back look at the pins for CAN1 prior to then P9 overlay
>> changes from last week by Robert.
> 
> What i suggested, assumed you were using a BBB.  Thus since you have a
> custom board, it's all null and void..
> 
> Use TI's pinmux tool and properly route your can signals.
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57260CA6-814D-4F21-8D3A-43A47490B236%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: u-boot support for pins

2017-11-01 Thread Tracy Smith

Agreed. And the pins are E18 and E17 for DCAN1_RX/TX on the BBB schematic. 
These are the pins the TI pinmux tools says use. So, trying to use these two 
pins for CAN1 because we don’t have the P9 expansion header. 

That is just the first step in this CAN bring up process for a custom BBB board 
that doesn’t have a P9 expansion header.  So I agree.

I still have a question for Robert, why is the P9 expansion header being used 
for then CAN on the most recent release instead of the AM335X CAN0 and CAN1 
RX/TX pins D17/D18 and E17/E18?

Thx, Tracy

> On Nov 1, 2017, at 1:28 PM, William Hermans  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 11:19 AM, Robert Nelson  
>> wrote:
>> On Wed, Nov 1, 2017 at 1:14 PM, Tracy Smith  wrote:
>> > E17 and E18 we want to use that are designated as possible CAN1 pins on the
>> > BeagleBone Black schematic.
>> >
>> > Not using a different overlay, using the existing 4.14 kernel and 2017 I
>> > boot that Robert Nelson suggests using for the BBB. But we need to pinmux
>> > for E17 and E18 because the TI pinmuxing tool finds no conflict with these
>> > two pins on our custom board. I’ll go back and check the CAN1 but prior to
>> > Roberts changes last week that did not use the P9 expansion header, the 
>> > unit
>> > pinmux used different pins CAN1 I believe.  With the P9 expansion header,
>> > can’t use Roberts overlay because there is no P9 expansion header on our 
>> > BBB
>> > board. I’ll go back look at the pins for CAN1 prior to then P9 overlay
>> > changes from last week by Robert.
>> 
>> What i suggested, assumed you were using a BBB.  Thus since you have a
>> custom board, it's all null and void..
>> 
>> Use TI's pinmux tool and properly route your can signals.
> 
> What Robert said, but in addition, it might be handy if you let us know what 
> hardware( everything ) you're using to help us, help you spot potential 
> hardware conflicts. I've worked on a project that did in fact use one CAN 
> interface a couple or three years ago. It works, but I only used one bus. Not 
> two. Additionally, I was using an older kernel, so I've not the same on a 
> current kernel. At some point I think I did test a semi recent kernel, just 
> to get the interface up and running, but I did not test the C code I wrote a 
> while back on that interface.
> 
> So how do you know it's not working. Just saying it doesn't work does not 
> give us the steps you taken to get where you are. or the error messages 
> you're getting, that could help us troubleshoot your issue for you. Nor does 
> it tell us if the driver for a given CAN interface is even loaded. You see 
> where I'm going ? There are many places for this process to go wrong.
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CALHSORpKGh0pYiYL5AjJuDUXqLHTwunYGS_uCaYHXqwkz4xBMg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8D713A70-D95F-455B-8CF4-74ABDA41866B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beaglebone] Unable to use WP8548 with ConnMan

2017-12-18 Thread Tracy Smith

Hi Robert,

What kernel and wpa_supplicant configuration changes are required to
enable a cellular connection and WiFi on Linux 14.4?

Or, do you have a page describing what is required to set up a
cellular connection with/without Connman, and a WiFI connection using
connman on the BeagleBone black with 14.4?

Have the kernel prompt and all interfaces working to my knowledge but
need to validate cellular connectivity and WiFi.

thx,
Tracy

On Fri, Dec 15, 2017 at 12:09 PM,   wrote:
> I'm trying to setup a WP8548 with ConnMan but I've a strange problem.
> ConnMan doesn't want to interact with the wireless adapter.
>
> Host platform: custom hardware based on the BeagleBone Black.
>
> Operating system: Linux kernel ver 3.14.29ltsi on mangOh Red adapter and
> Linux arm 4.14.0-rc5-bone2 on BeagleBone Black.
>
> mangOH Red versions:
>
> Firmware: SWI9X15Y_07.10.04.00 r32393 CARMD-EV-FRMWR1 2016/06/01 20:30:40
> Bootloader: SWI9X15Y_07.10.04.00 r32393 CARMD-EV-FRMWR1 2016/06/01 20:30:40
>
> The WP8548 Mango red is running, I can connect to a wifi network using the
> WP8548 Mango red so the wifi cellular network is working fine. I can access
> the AirVantage with no issues using the SIM card AT&T. Unable to see the
> wifi on the BeagleBone Black when the WP8548 Mago red is attached and
> connected to cellular wifi.  Trying to use ConnMan on the target BeagleBone
> Black to connect to the mango red wifi network.
>
> Below are the results of cm sim info and cm data on the mango read. Can ping
> the mangoh.io and connected with no issues. Everything set up correctly.
>
> root@swi-mdm9x15:~# cm sim info
> Type: EXTERNAL_SLOT_1man
> ICCID: 89011702272.
> Home Network Operator: AT&T
> IMSI: 31017
> Phone Number:
>
>
> root@swi-mdm9x15:~# cm data
> Index: 1
> APN: iot.aer.net
> PDP Type: IPV4V6
> Connected: yes
>
> Below the result of the "./connmanctl technologies" command:
>
> debian@arm:~$ connmanctl technologies
> /net/connman/technology/gadget
> Name = Gadget
> Type = gadget
> Powered = True
> Connected = False
> Tethering = False
>
> /net/connman/technology/ethernet
> Name = Wired
> Type = ethernet
> Powered = True
> Connected = False
> Tethering = False
>
> These are the 5 steps I understand are needed from previous posts to the TI
> community for the 3.14.281.0 Yocto Linux kernel. I have questions on steps
> 1, 2 and 5 in bold below.  I have also posted to the TI community, but they
> typically don't support the Beagle Bone Black community kernel/uboot.
>
> e2e.ti.com/.../58
>
> Step 1 used /etc/connman/main.conf as follows.
>
> Anything should be modified in main.conf to show wireless technologies?
>
> debian@arm:/etc/connman$ cat main.conf
> [General]
>
> # Set input request timeout. Default is 120 seconds
> # The request for inputs like passphrase will timeout
> # after certain amount of time. Use this setting to
> # increase the value in case of different user
> # interface designs.
> InputRequestTimeout = 120
>
> # Set browser launch timeout. Default is 300 seconds
> # The request for launching a browser for portal pages
> # will timeout after certain amount of time. Use this
> # setting to increase the value in case of different
> # user interface designs.
> BrowserLaunchTimeout = 300
>
> # Enable background scanning. Default is true.
> # Background scanning will start every 5 minutes unless
> # the scan list is empty. In that case, a simple backoff
> # mechanism starting from 10s up to 5 minutes will run.
> BackgroundScanning = true
>
> # List of Fallback timeservers separated by ",".
> # These timeservers are used for NTP sync when there are
> # no timeserver set by the user or by the service.
> # These can contain mixed combination of fully qualified
> # domain names, IPv4 and IPv6 addresses.
> # FallbackTimeservers =
>
> # List of fallback nameservers separated by "," used if no
> # nameservers are otherwise provided by the service. The
> # nameserver entries must be in numeric format, host
> # names are ignored.
> # FallbackNameservers =
>
> # List of technologies that are marked autoconnectable
> # by default, separated by commas ",". The default value
> # for this entry when empty is ethernet,wifi,cellular.
> # Services that are automatically connected must have been
> # set up and saved to storage beforehand.
> # DefaultAutoConnectTechnologies =
>
> # List of preferred technologies from the most preferred
> # one to the least preferred one separated by commas ",".
> # Services of the listed technology type will be tried one
> # by one in the order given, until one of them gets connected
> # or they are all tried. A service of a preferred technology
> # type in state 'ready' will get the default route when
> # compared to another preferred type further down the list
> # with state 'ready' or with a non-preferred type; a service
> # of a preferred technology type in state 'online' will get
> # the default route when compared to either a non-preferred
> # type or a preferred type further do

[beagleboard] Overlays and 4.14 Linux kernel for CAN

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

Re: [beagleboard] Overlays and 4.14 Linux kernel for CAN

[beagleboard] Re: Overlays and 4.14 Linux kernel for CAN

[beagleboard] u-boot support for pins

[beagleboard] Re: BBB- DCAN1 problems using latest debian image

[beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: BBB- DCAN1 problems using latest debian image

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: u-boot support for pins

Re: [beagleboard] Re: u-boot support for pins

[beagleboard] Re: [beaglebone] Unable to use WP8548 with ConnMan

19 matches

Site Navigation

Mail list logo

Footer information