Re: [beagleboard] Running CANbus on BBB w/ Chipsee BBB-EXP-C 7" display cape

1,552 views
Skip to first unread message
Message has been deleted

Robert Nelson

unread,
Jun 9, 2015, 4:48:28 PM6/9/15
to Beagle Board
On Tue, Jun 9, 2015 at 3:42 PM, Strong Industries <lor...@superdumps.com> wrote:
> Hello all!
>
> I am running a BBB (rev C) w/ the following system:
>
> 1. running "cat /etc/dogtag" at a command prompt outputs = "BeagleBoard.org
> Debian Image 2015-03-01"
>
> 2. running "uname -a"...Linux beaglebone 3.14.43-ti-r66 #1 SMP PREEMPT Fri
> May 22 22:36:39 UTC 2015 armv7l GNU/Linux (provided by Robert Nelson via
> "sudo apt-get install linux-image-3.14.43-ti-r66")
>
> 3. "cat /proc/version "...Linux version 3.14.43-ti-r66
> (root@a5-imx6q-wandboard-2gb) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP
> PREEMPT Fri May 22 22:36:39 UTC 2015
>
> 4. Chipsee BBB-EXP-C 7" touchscreen display cape
>
> 5. Connected BBB w/ BBB-EXP-C cape & wired the CANbus to a CR0403 PLC which
> is running a looped program
>
> 6. When I run "ifconfig can0" I get this output...
>
> can0 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> UP RUNNING NOARP MTU:16 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:1 overruns:0 carrier:1
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:68
>
> It looks like nothing is coming thru the CANbus. I've installed "can-utils"
> by following directions on this site, but that install seems to be missing
> the "canconfig" command described in a section talking about testing the
> CANbus on this website. Don't know what to do next w/ can-utils at this
> point.
>
>
> SO MY QUESTION IS...
> Has anyone gotten a configuration like this to work?

sudo ip link set can0 type can bitrate 125000
sudo ip link set can0 up

#receive:
./candump can0

Then from the other device....

#transmit:
./cansend can0 1F334455#1122334455667788

Regards,

--
Robert Nelson
https://rcn-ee.com/
Message has been deleted

Robert Nelson

unread,
Jun 9, 2015, 6:10:04 PM6/9/15
to Beagle Board
On Tue, Jun 9, 2015 at 5:00 PM, Strong Industries <lor...@superdumps.com> wrote:
> The "other device" is a CR0403 PLC which is running an independent OS by IFM
> (not networked to a linux system, so I can't ssh into it). The PLC device
> is transmitting over CANbus using a known working program which we already
> use in another system.
>
> When I do the "./candump can0", it hangs there w/ no output on the screen
> when I expect data coming from the PLC device (see attached pic)...
>
> I am lost here, because the only other thing I can think of is setting some
> type of DT overlay which I've read about on...
>
> https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay
>
> http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
>
> but those sites refer to Angstrom & using the cape manager (which I can't
> find the directories/files for in Debian).

Well, you already have can0 enabled on BBB-EXP-R cape by default... So
the above doesn't matter..

William Hermans

unread,
Jun 9, 2015, 7:47:07 PM6/9/15
to beagl...@googlegroups.com
You need to make sure the baud rate for the CAN interface is set correctly. e.g. you need to know the baud rate the PLC is transmitting at.

Also the screenshot you've given is normal behavior for candump. If you run candump, and it is unable to detect transmissions for whatever reason. It will just sit there as in your sceenshot, until you press control + C.

My initial guess would be that you have the baud rate set incorrectly. It *must* match that of the CAN interface you're connecting to.

Example:
debian@beaglebone:~$ sudo ip link set can0 up type can bitrate 250000

For us our baudrate is 250kbps so you can . . .

debian@beaglebone:~$ sudo ifconfig can0 down

debian@beaglebone:~$ sudo ip link set can0 up type can bitrate <your baud rate here >

debian@beaglebone:~$ sudo ifconfig can0 up


And then try again with candump. Also, I've read that if you do not use --listen-only with the ip command. Some devices will freak out, and stop transmitting. But we've not yet experienced that here.


--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Jun 9, 2015, 8:35:45 PM6/9/15
to beagl...@googlegroups.com
I suppose it is also possible you have your receive / transmit lines hooked up backwards. When first setting up here, that happened to us too.

When attempting to find the right baud rate for our system, a first incorrect value actually caused our BBB to lock up, and reset the external CAN device.

William Hermans

unread,
Jun 9, 2015, 8:51:33 PM6/9/15
to beagl...@googlegroups.com
Ah yeah. According to your device datasheet the default baud rate is 250kBit/s

Page 2 right column

CAN Interface 2.0 A/B, ISO 11898
20 kBit/s...1 MBit/s (Default CAN1: 250 kBit/s, CAN2: 250 kBit/s)
CANopen, CiA DS 301 Version 4, CiA DS 401 Version 1.4
oder SAE J 1939 oder freies Protokol

I'm afraid my German is not very good any more. But it looks like it uses the J1938 protocol as well.
Message has been deleted
Message has been deleted

William Hermans

unread,
Jun 10, 2015, 12:47:25 PM6/10/15
to beagl...@googlegroups.com
Yeah I do not know why, but it does seem you're using different sources than I used. Here are some "exact steps" I used to create a virtual can development machine. Note: That the only real differences I did here was using vcan, instead of a physical canX device. And vcan in this case does not need bit timing as the log files created have timestamps.

After many canplayer / candump sessions:

william@debian-can:~/can-dev$ sudo ifconfig vcan0
[sudo] password for william:
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:567011 errors:0 dropped:0 overruns:0 frame:0
          TX packets:567011 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4161973 (3.9 MiB)  TX bytes:4161973 (3.9 MiB)

However, this is in a virtual machine using 4GB RAM, and 4 cores @ 2.5Ghz. The speed between this virtual machine, and the BBB *is* very noticeable. You may consider using the same sources to build can-utils, if you can. They  may be newer / more up to date . . .but no guarantee it will make a difference. Also, you will have to make some changes obviously . . .

EXACT STEPS:

william@debian-can:~$ sudo apt-get install build-essential autoconf libtool git

william@debian-can:~$ mkdir dev
william@debian-can:~$ cd dev

william@debian-can:~/dev$ git clone https://github.com/linux-can/can-utils.git
Cloning into 'can-utils'...
remote: Counting objects: 1080, done.
remote: Total 1080 (delta 0), reused 0 (delta 0), pack-reused 1080
Receiving objects: 100% (1080/1080), 294.56 KiB | 106 KiB/s, done.
Resolving deltas: 100% (711/711), done.

william@debian-can:~/dev$ cd can-utils

william@debian-can:~/dev/can-utils$ ./autogen.sh

----------
autoreconf
----------

libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config/autoconf'.
libtoolize: copying file `config/autoconf/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `config/m4'.
libtoolize: copying file `config/m4/libtool.m4'
libtoolize: copying file `config/m4/ltoptions.m4'
libtoolize: copying file `config/m4/ltsugar.m4'
libtoolize: copying file `config/m4/ltversion.m4'
libtoolize: copying file `config/m4/lt~obsolete.m4'
libtoolize: Consider adding `-I config/m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:9: installing `config/autoconf/config.guess'
configure.ac:9: installing `config/autoconf/config.sub'
configure.ac:22: installing `config/autoconf/install-sh'
configure.ac:22: installing `config/autoconf/missing'
GNUmakefile.am: installing `config/autoconf/depcomp'

--------
Finished
--------

william@debian-can:~/dev/can-utils$ ./configure

william@debian-can:~/dev/can-utils$ make

william@debian-can:~/dev/can-utils$ sudo make install

william@debian-can:~$ sudo modprobe vcan
william@debian-can:~$ sudo ip link add vcan0 type vcan
william@debian-can:~$ sudo ip link set vcan0 up

william@debian-can:~$ sudo ifconfig vcan0
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


william@debian-can:~$ nc -l -p 5000 > /home/william/candump-may-14-2015.log

IMPORTANT: command switch -l will log to a file on the device. -L is necessary to pipe stdout in logfile format to netcat.

debian@xanbustester:~$ candump -L -n 20000 can1,0:0,#FFFFFFFF | nc 192.168.254.163 5000

After a few minutes use du to "test" if the incoming stream is finished. When it is finished, the file will stop growing.

william@debian-can:~$ du -h candump-may-14-2015.log
972K    candump-may-14-2015.log

william@debian-can:~$ tail candump-may-14-2015.log
(1425243434.234750) can1 19F00302#C9000000000000FF
(1425243434.249623) can1 19F0C503#E015031520AD0000
(1425243434.250165) can1 19F0C503#E17C010000100000
(1425243434.250783) can1 19F0C503#E200FFFFFFFFFC00
(1425243434.251412) can1 19F0C503#E300FFFFFFFFFFFF
(1425243434.259494) can1 19F0C503#00150303B2610000
(1425243434.260026) can1 19F0C503#0110FFFFFF060000
(1425243434.260629) can1 19F0C503#0200FFFFFFFFFC00
(1425243434.261197) can1 19F0C503#0300FFFFFFFFFFFF
(1425243434.269461) can1 19F0C502#C015030312610000

1st terminal
william@debian-can:~$ canplayer vcan0=can1 < candump-may-14-2015.log
2nd terminal
william@debian-can:~$ candump vcan0


  vcan0  19F0C503   [8]  E0 15 03 15 20 AD 00 00
  vcan0  19F0C503   [8]  E1 7C 01 00 00 10 00 00
  vcan0  19F0C503   [8]  E2 00 FF FF FF FF FC 00
  vcan0  19F0C503   [8]  E3 00 FF FF FF FF FF FF
  vcan0  19F0C503   [8]  00 15 03 03 B2 61 00 00
  vcan0  19F0C503   [8]  01 10 FF FF FF 06 00 00
  vcan0  19F0C503   [8]  02 00 FF FF FF FF FC 00
  vcan0  19F0C503   [8]  03 00 FF FF FF FF FF FF
  vcan0  19F0C502   [8]  C0 15 03 03 12 61 00 00

On Wed, Jun 10, 2015 at 9:21 AM, superD <lor...@superdumps.com> wrote:
ONE CONCERN HOWEVER...

I notice a lot of packets getting dropped (see pic attached) on can0...is that normal?

William Hermans

unread,
Jun 10, 2015, 12:51:23 PM6/10/15
to beagl...@googlegroups.com
Anyway, got to run for a while and do some work. If you have any further questions I can try and answer when I get back.

William Hermans

unread,
Jun 10, 2015, 2:56:24 PM6/10/15
to beagl...@googlegroups.com
One more thing that comes to mind that could be effecting your dropped packets. I'm running cmd line only on our BBB's. Where you're running X ( LXDE ? ).

It's been my experience with the BBB is that with X, it can be incredibly sluggish, depending on what you're doing. I have always guessed that this has to do with the BBB only having 512MB RAM, and X + running apps use up a lot of this. Anyway, it is possible that the combination of running X + whatever apps you're running is using up so much RAM that socketCAN + can-utils apps could be limited in how much RAM can be used for buffering. It is also possible that various things could be competing for CPU time.

So, if you must run X, and I'm guessing you must because of the LCD cape. Then I would explore how to limit memory and CPU usage while running X. e.g. reduce running apps to a minimum, and google around for memory / CPU optimization and minimization techniques.

William Hermans

unread,
Jun 10, 2015, 3:01:20 PM6/10/15
to beagl...@googlegroups.com
heh keep forgetting to add information . . . Anyway, no dropped packets on our BBB

debian@xanbustester:~$ sudo ifconfig can1
can1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:77659246 errors:0 dropped:77659246 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:572774448 (546.2 MiB)  TX bytes:0 (0.0 B)
          Interrupt:71

debian@xanbustester:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
debian@xanbustester:~$ uname -r
3.14.39-ti-r61

William Hermans

unread,
Jun 10, 2015, 3:05:44 PM6/10/15
to beagl...@googlegroups.com
errr looks like I was wrong. Many, many dropped RX packets. I was looking at TX. So . . . hmmmm yeah I do not know what to say. This does not affect our end goal though. As the application I'm writing tracks payload sequence numbers, and if any are out of order for the payload, they just get dumped . . .
Message has been deleted

William Hermans

unread,
Jun 10, 2015, 6:41:36 PM6/10/15
to beagl...@googlegroups.com
Well, I think using python for a timing critical application is probably a bad idea. Out of all languages, compiled, or not, Python is potentially the worst performance wise. It can be 80x + slower than javascript + google's V8 engine ( Nodejs ) even.

With that said, I think Nodejs would be a bad idea too. I've had some experience with Nodejs, and latency can sometimes be a problem.

Personally, I'm using C. But I have no idea of what your development constraints are. C++ could probably work well too. But since you'd be using C libraries for socketCAN . . .

I'll assume for now since you're using the cloud9 IDE, that you do not have another Linux machine, physical or virtual to work with ? Anyway, I personally think C is the way to go. Far less abstraction to get in the way, and socketCAN is fairly well documented.

https://www.kernel.org/doc/Documentation/networking/can.txt

On Wed, Jun 10, 2015 at 3:13 PM, superD <lor...@superdumps.com> wrote:
Haven't tried the "vcan0" stuff so far.  Just observing to see how the CAN bus is working w/ the dropped packets (see screenshot from Cloud9 terminal).  I see what you mean by LXDE possibly causing the interference.  Ultimately, I'd like it to boot up the application I'm going to create w/ it's interface (creating the GUI w/ PyQt & QT designer currently) instead of LXDE; which I *think* I can do by placing the program in the AUTORUN folder of Cloud9 (as posted here https://www.npmjs.com/package/bonescript#launching-applications-persistently).

What is the easiest way to develop CAN bus applications?  I've started w/ Python & got stuck b/c "Python-Can" needs at least python 3.3 (which apparently isn't available for Debian).

I ran..."apt-cache search python | egrep "^python3.[0-9] " --color"...and it gave me...

python3.2 - Interactive high-level object-oriented language (version 3.2)

Suggestions?

William Hermans

unread,
Jun 10, 2015, 6:46:27 PM6/10/15
to beagl...@googlegroups.com
By the way, I'm still learning a lot about all this too. For all intents and purposes this is the first major application I've written on Linux. Also a couple months ago I knew absolutely nothing about the subject. Which for me includes socketcan, J1939, NEMA 2000 / NEMA 2000 fast packet.

Anyway, my point is: If I can do this, I'm sure you can too.

William Hermans

unread,
Jun 10, 2015, 8:24:20 PM6/10/15
to beagl...@googlegroups.com
Hey SuperD I just realized something.

Look at the output of my ifconfig for our BBB with logic supply serial / CAN cape. Notice anything odd ? As in 100% dropped packets ? heh

I just dawned on me, that since the BBB last started we've not used the CANBus at all. It is attached to our external CAN device, but no socketCAN apps ( including candump ) have been run since last restart . . .Which means I believe this is just normal behavior.

Try it yourself. restart your BBB, and do not use candump just let it sit there for a little while. I'm willing to bet you'll also notice 100% packet loss.
Message has been deleted

William Hermans

unread,
Jun 10, 2015, 10:13:05 PM6/10/15
to beagl...@googlegroups.com
OK, first I should point out that specific to the beaglebone is not necessary. Linux is Linux, socketCAN is socketCAN.

Second, the github project for socketCAN / can-utils has example code. But I found that for me personally the examples were rather terse reading.

https://github.com/linux-can/can-utils

Thirdly, I found once I started learning more about socketCAN, that I could google keywords like "frame->can_id" ( struct can_frame frame; ) that I could find example code, that would help me understand things better.

Last, but not least. all but excessive google sessions on every variation of different keywords to find out what I needed to understand. All that, and I'm still learning.

This link http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/ Helped me understand various things early on, and gave me some rough ideas as to how I could reverse engineer the protocol our external CAN device uses. While at the same time, my buddy a long time oldschool electronics engineer, reversed the protocol by hand to find out which protocol it was, the actual meanings of various fields. Close enough to where I have a much better understanding of things like, what the can_id fields actually means for our protocol. Then stuff like the basics of how the frame->data payload(s) are structured.

In short, the protocol our device uses is much more complex than the one your PLC seems to be using. It's NEMA 2000 fast packet, and the data most of the time spans multiple CAN frames. For each PGN.Where as your PLC only seems to use single frames per payload. I do not recognize the protocol offhand though . . . seems like it could be based on SAE J1939, but the can_id fields do not look familiar to me.

Anyway, here is a very simple socketCAN example app I wrote to get my own feet wet.

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/can.h>
#include <linux/can/raw.h>
#include <net/if.h>
#include <sys/ioctl.h>

static int sock;

static int can_init(char *ifname){

    struct sockaddr_can addr;
    struct ifreq ifr;

    sock = socket(PF_CAN, SOCK_RAW, CAN_RAW);
    if (sock < 0){
        perror("Unable to create socket.");
        exit(1);
    }

    memset(&ifr.ifr_name, 0, sizeof(ifr.ifr_name));
    strncpy(ifr.ifr_name, ifname, IFNAMSIZ);

    if (ioctl(sock, SIOCGIFINDEX, &ifr) < 0) {
        perror("SIOCGIFINDEX");
        exit(1);
    }

    memset(&addr, 0, sizeof(addr));
    addr.can_family = AF_CAN;
    addr.can_ifindex = ifr.ifr_ifindex;
    if(bind(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0){
        perror("Unable to bind to socket");
        exit(1);
    }

    return 0;
}

static void read_can_frame(void){

    struct can_frame frame;
    int nbytes;
    int i;

    nbytes = read(sock, &frame, sizeof(struct can_frame));

    if (nbytes < 0) {
            perror("can raw socket read");
            exit(1);
    }
    printf("  Recv :  %03X      ", frame.can_id);

    for (i = 0; i < frame.can_dlc; i++){

        printf(" %02X", frame.data[i]);
    }

    printf("\n");
}

int main(int argc, char *argv[]) {

    can_init("vcan0");

    while(1){
        read_can_frame();
    }

    return 0;
}
The output is very similar to candump, except that is does not check for:

frame->can_id & CAN_ERR_FLAG, frame->can_id & CAN_EFF_FLAG, 
frame->can_id & CAN_SFF_FLAG

Or mask out the frame->can_id like is done in candump. Thus the 
can_id fields will show differently than is shown from the
candump output. This was pointed out to me by another person, 
after which I was able to correct my test code.

On Wed, Jun 10, 2015 at 6:21 PM, superD <lor...@superdumps.com> wrote:
William,
You are correct about that packet loss issue (see attached pic).  As far as the programming, do you know of a github (or similar resource) that has programming examples of CAN bus apps for BBB?  That would help a lot in steering me the right way with the development of this project. 

I am also new to GUI development; which is why I chose PyQt & Qt Designer (almost "Dreamweaver-like" feel), BUT...I'm open to options (programming language & GUI tools) if they're truly better for performance overall.

Currently using Windows 8, but Debian Linux is on the BBB & I can VNC into it using "x11vnc" (acquired thru "apt-get install x11vnc") and TightVNC for Windows

William Hermans

unread,
Jun 10, 2015, 10:25:17 PM6/10/15
to beagl...@googlegroups.com
As for GUI apps go. Qt will probably do a good job for you. I've never really used it much, and only for simple things on Windows. While toying with it. After watching this series of videos when bored one week . . .

https://www.youtube.com/watch?v=aMUh9DmFLto

Ross Morrison

unread,
Jun 30, 2015, 5:24:55 PM6/30/15
to beagl...@googlegroups.com
Hello all,

I haven't been keeping up with all the ins and outs of the 4.1.0-boneXX
kernel. I've downloaded the testing image 4.1.0-bone9 and am curious as
to how to get UART4 running?

Thanks for any direction on this subject,

Ross



Robert Nelson

unread,
Jun 30, 2015, 5:27:51 PM6/30/15
to Beagle Board
open:

/boot/uEnv.txt

find:

#cape_enable=bone_capemgr.enable_partno=

Change to:
cape_enable=bone_capemgr.enable_partno=BB-UART4

reboot..

Ross Morrison

unread,
Jun 30, 2015, 5:32:17 PM6/30/15
to beagl...@googlegroups.com
Thanks for the super quick response Robert, but here is what I have in
uEnv.txt and what dmesg shows:

snippet from uEnv.txt
=======================
#HDMI/eMMC disabled:
dtb=am335x-boneblack-overlay.dtb

##cape-universal
#dtb=am335x-boneblack-universal.dtb

##wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##replicape
#dtb=am335x-boneblack-replicape.dtb
cmdline=coherent_pool=1M quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=BB-UART4

#Disable HDMI/eMMC
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
cape_enable=bone_capemgr.enable_partno=BB-UART4

##Disable HDMI
===================================


snipped from dmesg:
===============================================================

[ 3.232255] bone_capemgr bone_capemgr: slot #0: No cape found
[ 3.292247] bone_capemgr bone_capemgr: slot #1: No cape found
[ 3.352245] bone_capemgr bone_capemgr: slot #2: No cape found
[ 3.412239] bone_capemgr bone_capemgr: slot #3: No cape found
[ 3.418291] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART4' VER 'N/A' PR '0'
[ 3.418305] bone_capemgr bone_capemgr: slot #4: override
[ 3.418318] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[ 3.418332] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART4'
[ 3.418537] bone_capemgr bone_capemgr: initialized OK.
[ 3.462319] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[ 3.482246] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 3.482257] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 3.482551] davinci_mdio: dt: updated phy_id[0] from phy_mask[fffffffe]
[ 3.482574] davinci_mdio: dt: updated phy_id[1] from phy_mask[fffffffe]
[ 3.487411] libphy: 4a101000.mdio: probed
[ 3.487437] davinci_mdio 4a101000.mdio: phy[0]: device
4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 3.488107] cpsw 4a100000.ethernet: Detected MACID = 78:a5:04:c0:f7:5f
[ 3.489340] omap_rtc 44e3e000.rtc: setting system clock to 2015-06-30
21:16:52 UTC (1435699012)
[ 3.489366] of_cfs_init
[ 3.489456] of_cfs_init: OK
[ 3.492823] PM: Hibernation image not present or could not be loaded.
[ 3.493672] Freeing unused kernel memory: 444K (c094f000 - c09be000)
[ 3.573293] systemd-udevd[85]: starting version 215
[ 3.575088] random: systemd-udevd urandom read with 8 bits of entropy
available
[ 3.967295] usb 1-1: New USB device found, idVendor=148f, idProduct=7601
[ 3.967314] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 4.422344] bone_capemgr bone_capemgr: loader: failed to load slot-4
BB-UART4:00A0 (prio 0)
[ 9.145277] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
=====================================================================

at 4.422344 it appears there was a failure???

Thanks,
Ross

William Hermans

unread,
Jun 30, 2015, 6:12:09 PM6/30/15
to beagl...@googlegroups.com
[    3.232255] bone_capemgr bone_capemgr: slot #0: No cape found

[    3.292247] bone_capemgr bone_capemgr: slot #1: No cape found
[    3.352245] bone_capemgr bone_capemgr: slot #2: No cape found
[    3.412239] bone_capemgr bone_capemgr: slot #3: No cape found
[    3.418291] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART4' VER 'N/A' PR '0'
[    3.418305] bone_capemgr bone_capemgr: slot #4: override
[    3.418318] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[    3.418332] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART4'
[    3.418537] bone_capemgr bone_capemgr: initialized OK.

...

[    4.422344] bone_capemgr bone_capemgr: loader: failed to load slot-4 BB-UART4:00A0 (prio 0)

Am I reading this right ? Almost seems as though it is trying to load twice, and the error is the second instance trying to load.

Maybe dmesg | grep uart will shed some light on the subject ? Or maybe dmesg | grep cape.

--

Robert Nelson

unread,
Jun 30, 2015, 6:12:35 PM6/30/15
to Beagle Board
On Tue, Jun 30, 2015 at 4:32 PM, Ross Morrison <ro...@buy-ei.com> wrote:
> Thanks for the super quick response Robert, but here is what I have in
> uEnv.txt and what dmesg shows:
>
> snippet from uEnv.txt
> =======================
> #HDMI/eMMC disabled:
> dtb=am335x-boneblack-overlay.dtb
>
> ##cape-universal
> #dtb=am335x-boneblack-universal.dtb
>
> ##wl1835
> #dtb=am335x-boneblack-wl1835mod.dtb
>
> ##replicape
> #dtb=am335x-boneblack-replicape.dtb
> cmdline=coherent_pool=1M quiet
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M quiet video=HDMI-A-1:1024x768@60e
>
> ##Example v3.8.x
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> #cape_enable=bone_capemgr.enable_partno=BB-UART4
>
> #Disable HDMI/eMMC
> cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

This ^^ is for v3.8.x, don't confuse 4.1.x...

> cape_enable=bone_capemgr.enable_partno=BB-UART4

debian@beaglebone:~$ cat /boot/uEnv.txt | grep UART
Loaded here:


debian@beaglebone:~$ dmesg | grep capemgr
[ 0.000000] Kernel command line: console=ttyO0,115200n8
bone_capemgr.enable_partno=BB-UART4
root=UUID=20b61701-5d1b-44c4-baec-5d8d4c40dba2 ro rootfstype=ext4
rootwait fixrtc coherent_pool=1M quiet
[ 3.220199] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,000C,2115BBBK0347'
[ 3.220222] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 3.272316] bone_capemgr bone_capemgr: slot #0: No cape found
[ 3.332301] bone_capemgr bone_capemgr: slot #1: No cape found
[ 3.392300] bone_capemgr bone_capemgr: slot #2: No cape found
[ 3.452299] bone_capemgr bone_capemgr: slot #3: No cape found
[ 3.458340] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART4' VER 'N/A' PR '0'
[ 3.458351] bone_capemgr bone_capemgr: slot #4: override
[ 3.458364] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 3.458377] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART4'
[ 3.458606] bone_capemgr bone_capemgr: initialized OK.
[ 3.475352] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-UART4-00A0.dtbo' loaded; overlay id #0

debian@beaglebone:~$ dmesg | grep serial
[ 3.052993] omap_uart 44e09000.serial: no wakeirq for uart0
[ 3.053158] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 154,
base_baud = 3000000) is a OMAP UART0
[ 3.474825] omap_uart 481a8000.serial: no wakeirq for uart4
[ 3.474983] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 180,
base_baud = 3000000) is a OMAP UART4

debian@beaglebone:~$ uname -r
4.1.0-bone9
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-06-29

I only added the one line change to /boot/uEnv.txt...

Ross Morrison

unread,
Jun 30, 2015, 6:28:45 PM6/30/15
to beagl...@googlegroups.com
Yea, I had caught that mistake on the cape_enable line. That is taken
care of.

Here is the complete /boot/uEnv.txt.

=======================

root@bbb-blackbox:~# cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.1.0-bone9
#dtb=

##BeagleBone Black dtb's for v4.1.x (BeagleBone White just works..)

##HDMI/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb

##cape-universal
#dtb=am335x-boneblack-universal.dtb

##wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##replicape
#dtb=am335x-boneblack-replicape.dtb
cmdline=coherent_pool=1M quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

#Disable HDMI/eMMC
cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
cape_enable=bone_capemgr.enable_partno=BB-UART4

##Disable HDMI
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable BBB: eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

root@bbb-blackbox:~#
=======================

here are some greps from dmesg

===========================
root@bbb-blackbox:~# dmesg | grep UART
[ 0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
bone_capemgr.enable_partno=BB-UART4 root=/dev/mmcblk0p1 rootfstype=ext4
rootwait fixrtc coherent_pool=1M quiet
[ 3.054227] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 154,
base_baud = 3000000) is a OMAP UART0
[ 3.468496] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART4' VER 'N/A' PR '0'
[ 3.468534] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART4'
[ 4.472472] bone_capemgr bone_capemgr: loader: failed to load slot-4
BB-UART4:00A0 (prio 0)
root@bbb-blackbox:~#

root@bbb-blackbox:~# dmesg | grep cape
[ 0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
bone_capemgr.enable_partno=BB-UART4 root=/dev/mmcblk0p1 rootfstype=ext4
rootwait fixrtc coherent_pool=1M quiet
[ 3.222538] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,3214BBBK1283'
[ 3.222565] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 3.282380] bone_capemgr bone_capemgr: slot #0: No cape found
[ 3.342488] bone_capemgr bone_capemgr: slot #1: No cape found
[ 3.402388] bone_capemgr bone_capemgr: slot #2: No cape found
[ 3.462435] bone_capemgr bone_capemgr: slot #3: No cape found
[ 3.468496] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-UART4' VER 'N/A' PR '0'
[ 3.468507] bone_capemgr bone_capemgr: slot #4: override
[ 3.468520] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[ 3.468534] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-UART4'
[ 3.468779] bone_capemgr bone_capemgr: initialized OK.
[ 4.472472] bone_capemgr bone_capemgr: loader: failed to load slot-4
BB-UART4:00A0 (prio 0)
root@bbb-blackbox:~#

root@bbb-blackbox:~# dmesg | grep uart
[ 3.054068] omap_uart 44e09000.serial: no wakeirq for uart0
root@bbb-blackbox:~#

===========================

This was the console image

microSD/Standalone: (console) (BeagleBone/BeagleBone Black)

wgethttps://rcn-ee.com/rootfs/bb.org/testing/2015-06-29/console/bone-debian-8.1-console-armhf-2015-06-29-2gb.img.xz
md5sum: 34d877d57c57ff1d6bc27685ea88b42f


This is what I know........

Thanks,
Ross

Robert Nelson

unread,
Jun 30, 2015, 6:37:27 PM6/30/15
to Beagle Board
Disable this line ^ as
"BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G" is NOT enabled in
v4.1.x, if you want hdmi/eMMC disabled use
dtb=am335x-boneblack-overlay.dtb
ah "console" lead with that next time.. Only the lxqt images have
"everything" ready to go..

sudo apt-get update ; sudo apt-get install git-core

git clone https://github.com/beagleboard/bb.org-overlays
cd bb.org-overlays

./dtc-overlay.sh
./install.sh

sudo reboot

Ross Morrison

unread,
Jun 30, 2015, 6:47:19 PM6/30/15
to beagl...@googlegroups.com
Life is good. Sorry about not specifying it was a console only image.

Thanks for help on this one and all your great work on these releases.

Ross
Reply all
Reply to author
Forward
0 new messages