My first BBB Cape...

GoogleGroups
1

OK, my PCBs arrived today (from PCBWAY) and I assembled one (See:
https://github.com/RobertPHeller/RPi-RRCircuits/tree/master/LCCCANCape).

I plugged the cape board on and bone_capemgr sees it: (dmesg output)

[ 1.352490] bone_capemgr bone_capemgr: slot #0: No cape found
[ 1.381015] bone_capemgr bone_capemgr: slot #1: No cape found
[ 1.407867] bone_capemgr bone_capemgr: slot #2: No cape found
[ 1.431906] bone_capemgr bone_capemgr: slot #3: 'LCCCANCape ,0001,DeepwoodsSoftwar,0003 '
[ 1.432279] bone_capemgr bone_capemgr: initialized OK.
[ 1.437192] bone_capemgr bone_capemgr: loader: failed to load slot-3 0003 :0001 (prio 0)

I guess now I need to configure something somewhere so that bone_capemgr can
load the proper overlay file(s).

All this cape does is connect P9-24 (CAN1-RX) and P9-26 (CAN1-TX) to a
TCAN332DR CAN Tranceiver and then on to a pair of RJ45 jacks.

I *think* I can just use BB-CAN1-00A0.dtbo, but I am guessing that somehow I
need to let bone_capemgr know that it should load this overlay for this cape.

And then I need to get dcan1's socket device brought up.

I'm assuming the driver is compiled into the kernel: 4.14.108-ti-r106:

from /boot/config-4.14.108-ti-r106:

CONFIG_CAN_C_CAN=y
CONFIG_CAN_C_CAN_PLATFORM=y

2

Is there *current* and *correct* documentation about uBoot, uEnv.txt, capemgr,
and CAN for the Beagle Bone Black? All of the hits I am getting doing web
searches are for older pages, most of which do not work (or don't seem to
work) with a current kernel (4.14.108-ti-r106). Or do I need a different
kernel?

3

Both implementations read the eeprom the same way and load the
approprate overlay..

Your "written" eeprom is wrong..

Look at the examples *.dump here:

https://github.com/RobertCNelson/boot-scripts/tree/master/device/bone/capes

For debugging connect a usb-serial adapter and look at what u-boot is
reading from your eeprom and trying to load:

Grab the latest stretch-console, as it has the latest version of
u-boot and the eeprom read/debug information..

https://rcn-ee.net/rootfs/bb.org/testing/2019-06-23/stretch-console/

Regards,

4

>
> Is there *current* and *correct* documentation about uBoot, uEnv.txt, capemgr,
> and CAN for the Beagle Bone Black? All of the hits I am getting doing web
> searches are for older pages, most of which do not work (or don't seem to
> work) with a current kernel (4.14.108-ti-r106). Or do I need a different
> kernel?

Both implementations read the eeprom the same way and load the
approprate overlay..

Your "written" eeprom is wrong..

Look at the examples *.dump here:

boot-scripts/device/bone/capes at master · RobertCNelson/boot-scripts · GitHub

OK, now I am throughly confused. I wrote the cape eeprom based on the
documentation in the "BeagleBone Black System Reference Manual", Revision A4,
January 2, 2013, Table 9 on page 62 and Table 10 on page 64.

The cape EEProms in /opt/scripts/device/bone/capes/ don't appear to match the
above documentation. Is that documentation wrong? Where is the correct
documentation?

5

I doubt the documentation is wrong, we've been doing it the same way
since 3.8.x, that's been like 10 years ago now..

Here is another example for reference:

[ 2.343333] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,000C,1713BBBG1255'
[ 2.343368] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.382090] bone_capemgr bone_capemgr: slot #0:
'nh7cape,A0,Cembsoft,BB-BONE-NH7C-01'
[ 2.421993] bone_capemgr bone_capemgr: slot #1: No cape found
[ 2.461987] bone_capemgr bone_capemgr: slot #2: No cape found
[ 2.501988] bone_capemgr bone_capemgr: slot #3: No cape found
[ 2.502246] bone_capemgr bone_capemgr: initialized OK.
[ 3.514365] bone_capemgr bone_capemgr: loader: failed to load
slot-0 BB-BONE-NH7C-01:A0 (prio 0)

The eeprom had:

'nh7cape,A0,Cembsoft,BB-BONE-NH7C-01'

So it looks for the file: "BB-BONE-NH7C-01-A0.dtbo" so by comma's: $4:$2

in memory the eeprom is:

struct am335x_cape_eeprom_id {
unsigned int header;
char eeprom_rev[2];
char board_name[32];
char version[4];
char manufacture[16];
char part_number[16];
char number_of_pins[2];
char serial_number[12];
char pin_usage[140];
char vdd_3v3exp[ 2];
char vdd_5v[ 2];
char sys_5v[2];
char dc_supplied[2];
};

nothing beyond using part_number,version was "ever" utilized in the
original 3.8 kernel..

Regards,

6

>
> Is there *current* and *correct* documentation about uBoot, uEnv.txt, capemgr,
> and CAN for the Beagle Bone Black? All of the hits I am getting doing web
> searches are for older pages, most of which do not work (or don't seem to
> work) with a current kernel (4.14.108-ti-r106). Or do I need a different
> kernel?

Both implementations read the eeprom the same way and load the
approprate overlay..

Your "written" eeprom is wrong..

Look at the examples *.dump here:

boot-scripts/device/bone/capes at master · RobertCNelson/boot-scripts · GitHub

For debugging connect a usb-serial adapter and look at what u-boot is
reading from your eeprom and trying to load:

How is it *physically* possible to connect a serial cable to the UART0 header
AND install a cape? (I guess I can use a pair of stacking headers to raise
the cape up.)

Grab the latest stretch-console, as it has the latest version of
u-boot and the eeprom read/debug information..

https://rcn-ee.net/rootfs/bb.org/testing/2019-06-23/stretch-console/

Which files do I grab here, there seem to be a whole assortment.

7

Is there current and correct documentation about uBoot, uEnv.txt, capemgr,

and CAN for the Beagle Bone Black? All of the hits I am getting doing web

searches are for older pages, most of which do not work (or don’t seem to

work) with a current kernel (4.14.108-ti-r106). Or do I need a different

kernel?

Both implementations read the eeprom the same way and load the

approprate overlay…

Your “written” eeprom is wrong…

Look at the examples *.dump here:

https://github.com/RobertCNelson/boot-scripts/tree/master/device/bone/capes

For debugging connect a usb-serial adapter and look at what u-boot is

reading from your eeprom and trying to load:

How is it physically possible to connect a serial cable to the UART0 header
AND install a cape? (I guess I can use a pair of stacking headers to raise
the cape up.)

Stacking headers is one option. Personally, I use:

https://www.tindie.com/products/spirilis/beaglebone-black-ftdi-friction-fit/

8

>
>
>>
>>>
>>> Is there *current* and *correct* documentation about uBoot, uEnv.txt, capemgr,
>>> and CAN for the Beagle Bone Black? All of the hits I am getting doing web
>>> searches are for older pages, most of which do not work (or don't seem to
>>> work) with a current kernel (4.14.108-ti-r106). Or do I need a different
>>> kernel?
>>
>> Both implementations read the eeprom the same way and load the
>> approprate overlay..
>>
>> Your "written" eeprom is wrong..
>>
>> Look at the examples *.dump here:
>>
>> boot-scripts/device/bone/capes at master · RobertCNelson/boot-scripts · GitHub
>>
>> For debugging connect a usb-serial adapter and look at what u-boot is
>> reading from your eeprom and trying to load:
>
> How is it *physically* possible to connect a serial cable to the UART0 header
> AND install a cape? (I guess I can use a pair of stacking headers to raise
> the cape up.)

Stacking headers is one option. Personally, I use:

https://www.tindie.com/products/spirilis/beaglebone-black-ftdi-friction-fit/

That link goes to a completely blank page. At least on my browser (Firefox
60.7.0esr, 64bit). (It could also be because of my dialup connection.) OK,
visiting with Lynx it tells me that the product is retired and no longer
available...

9

on my boards i designed a passthrough connector that plugs in like the headers.

10

on my boards i designed a passthrough connector that plugs in like the
headers.

Hmm.... Interesting idea. Too late for my boards, but maybe a future rev...

11

>
> Is there *current* and *correct* documentation about uBoot, uEnv.txt, capemgr,
> and CAN for the Beagle Bone Black? All of the hits I am getting doing web
> searches are for older pages, most of which do not work (or don't seem to
> work) with a current kernel (4.14.108-ti-r106). Or do I need a different
> kernel?

Both implementations read the eeprom the same way and load the
approprate overlay..

Your "written" eeprom is wrong..

Look at the examples *.dump here:

boot-scripts/device/bone/capes at master · RobertCNelson/boot-scripts · GitHub

For debugging connect a usb-serial adapter and look at what u-boot is
reading from your eeprom and trying to load:

This is what I am getting on the serial console:

U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
bad magic

U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274

       Watchdog enabled
I2C: ready
DRAM: 512 MiB
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
2106 bytes read in 31 ms (65.4 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.14.108-ti-r106 ...
9925120 bytes read in 576 ms (16.4 MiB/s)
loading /boot/dtbs/4.14.108-ti-r106/am335x-boneblack.dtb ...
60317 bytes read in 59 ms (998 KiB/s)
loading /boot/initrd.img-4.14.108-ti-r106 ...
4695471 bytes read in 294 ms (15.2 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ...
debug: [bootz 0x82000000 0x88080000:47a5af 0x88000000] ...
Kernel image @ 0x82000000 [ 0x000000 - 0x977200 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 8fb85000, end 8ffff5af ... OK
   Loading Device Tree to 8fb73000, end 8fb84b9c ... OK

Starting kernel ...

[ 0.000775] timer_probe: no matching timers found
[ 0.883249] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 1.126851] omap_voltage_late_init: Voltage driver support not added
[ 1.133957] PM: Cannot get wkup_m3_ipc handle
[ 1.460685] bone_capemgr bone_capemgr: loader: failed to load slot-0 BB-CAN1:00A0 (prio 0)
[ 1.472004] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: no source widget found for Playback
[ 1.480985] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: Failed to add route Playback -> direct -> TX
rootfs: clean, 102623/1870848 files, 746903/7571456 blocks

My cape's eeprom is now set up to load BB-CAN1-00A0.dtbo, which exists in
/lib/firmware/.

I'm not really sure how to debug this. I can stop the normal boot process in
uboot, but I don't know what I should be doing to debug things at that point.
Where is bone_capemgr? More importantly, where is its configuration files?
How can I get it so spit out more information about what it is doing/not
doing? Find out what file(s) it is actually trying to load (eg where is it
looking for overlays)?

Grab the latest stretch-console, as it has the latest version of
u-boot and the eeprom read/debug information..

https://rcn-ee.net/rootfs/bb.org/testing/2019-06-23/stretch-console/

What do I do with these files? Do I dd one of the .img files to the uSD card?
If so, which one? (Can I in fact do that without trashing the existing root
file system?)

12

Thanks!

This is what I am getting on the serial console:

U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
bad magic

U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274

Way too old.. That doesn't support u-boot overlays..

My cape's eeprom is now set up to load BB-CAN1-00A0.dtbo, which exists in
/lib/firmware/.

I'm not really sure how to debug this. I can stop the normal boot process in
uboot, but I don't know what I should be doing to debug things at that point.
Where is bone_capemgr? More importantly, where is its configuration files?
How can I get it so spit out more information about what it is doing/not
doing? Find out what file(s) it is actually trying to load (eg where is it
looking for overlays)?

Your version of u-boot loading is too old, it's probally the one
stored on the eMMC, just clear it out via, which will erase your
eMMC...

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

> Grab the latest stretch-console, as it has the latest version of
> u-boot and the eeprom read/debug information..
>
> https://rcn-ee.net/rootfs/bb.org/testing/2019-06-23/stretch-console/

What do I do with these files? Do I dd one of the .img files to the uSD card?
If so, which one? (Can I in fact do that without trashing the existing root
file system?)

Here's a version with directions:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Console_Snapshot

and yes, you will dd/etcher.io/etc them to a microSD, so your microSD
will be erased..

Regards,

13

Thanks!

> This is what I am getting on the serial console:
>
> U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
> bad magic
>
> U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274

Way too old.. That doesn't support u-boot overlays..

> My cape's eeprom is now set up to load BB-CAN1-00A0.dtbo, which exists in
> /lib/firmware/.
>
> I'm not really sure how to debug this. I can stop the normal boot process in
> uboot, but I don't know what I should be doing to debug things at that point.
> Where is bone_capemgr? More importantly, where is its configuration files?
> How can I get it so spit out more information about what it is doing/not
> doing? Find out what file(s) it is actually trying to load (eg where is it
> looking for overlays)?

Your version of u-boot loading is too old, it's probally the one
stored on the eMMC, just clear it out via, which will erase your
eMMC...

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

>
>
> > Grab the latest stretch-console, as it has the latest version of
> > u-boot and the eeprom read/debug information..
> >
> > https://rcn-ee.net/rootfs/bb.org/testing/2019-06-23/stretch-console/
>
> What do I do with these files? Do I dd one of the .img files to the uSD card?
> If so, which one? (Can I in fact do that without trashing the existing root
> file system?)

Here's a version with directions:

Beagleboard:BeagleBoneBlack Debian - eLinux.org

and yes, you will dd/etcher.io/etc them to a microSD, so your microSD
will be erased..

OK, so that means I need to backup my root file system, and then restore it,
right after copying the boot console to it?

14

Thanks!

> This is what I am getting on the serial console:
>
> U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
> bad magic
>
> U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274

Way too old.. That doesn't support u-boot overlays..

> My cape's eeprom is now set up to load BB-CAN1-00A0.dtbo, which exists in
> /lib/firmware/.
>
> I'm not really sure how to debug this. I can stop the normal boot process in
> uboot, but I don't know what I should be doing to debug things at that point.
> Where is bone_capemgr? More importantly, where is its configuration files?
> How can I get it so spit out more information about what it is doing/not
> doing? Find out what file(s) it is actually trying to load (eg where is it
> looking for overlays)?

Your version of u-boot loading is too old, it's probally the one
stored on the eMMC, just clear it out via, which will erase your
eMMC...

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Ha! Doing the above was all I needed to do. The UBoot on my *uSD card* is new
enough to load the cape overlay. Once I nuked the eMMC, it loaded the cape
overlay.

Now I need to start the CAN driver and allocate a SocketCAN device (eg dcan1).

Most of the websearches I have done resulted in *old* pages, all of which
don't work with the Debian 9 system I have running on my Beagle.