Cape EEROMs in uboot systems

GoogleGroups
1

I have a prototype cape with the EEROM programmed as follows:

root@beaglebone2GB:/home/john/One-Wire# cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C
00000000 aa 55 33 ee 41 30 4f 6e 65 57 69 72 65 20 70 6c |.U3.A0OneWire pl|
00000010 75 73 20 43 41 4e 62 75 73 00 00 00 00 00 00 00 |us CANbus…|
00000020 00 00 00 00 00 00 30 30 41 30 41 75 74 6f 41 72 |…00A0AutoAr|
00000030 74 69 73 61 6e 73 20 49 6e 63 42 42 2d 57 31 2d |tisans IncBB-W1-|
00000040 50 38 2e 31 31 00 00 00 00 00 00 00 00 00 00 00 |P8.11…|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|

2

I have a prototype cape with the EEROM programmed as follows:

root@beaglebone2GB:/home/john/One-Wire# cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C
00000000 aa 55 33 ee 41 30 4f 6e 65 57 69 72 65 20 70 6c |.U3.A0OneWire pl|
00000010 75 73 20 43 41 4e 62 75 73 00 00 00 00 00 00 00 |us CANbus.......|
00000020 00 00 00 00 00 00 30 30 41 30 41 75 74 6f 41 72 |......00A0AutoAr|
00000030 74 69 73 61 6e 73 20 49 6e 63 42 42 2d 57 31 2d |tisans IncBB-W1-|
00000040 50 38 2e 31 31 00 00 00 00 00 00 00 00 00 00 00 |P8.11...........|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00008000
r

Needless to say with the demise of the $SLOTS concept this tutorial is no longer valid so I'd like to rewrite it so it is valid.
https://www.cs.sfu.ca/CourseCentral/433/bfraser/other/2016-student-howtos/DS18B20Thermometer.pdf

Using this dts as a guide
bb.org-overlays/src/arm/BB-CAN0-00A0.dts at 5741f63c1ee922333dca02d9763edae03d477c96 · beagleboard/bb.org-overlays · GitHub

I've modified the BB-W1-P9.12-00A0.dts to become BB-W1-P8.11-00A0.dts shown below.

debian@ebb:~/bb.org-overlays/src/arm$ cat BB-W1-P8.11*
/*
*
* Virtual cape for onewire on connector pin P8.11
* derived from BB-W1-P9.12-00A0.dts
* by John Dammeyer MAR2019
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/

/dts-v1/;
/plugin/;

#include <dt-bindings/board/am335x-bbw-bbb-base.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>

/ {
        compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";

        /* identification */
        part-number = "BB-W1-P8.11";
        version = "00A0";

        /* state the resources this cape uses */
        exclusive-use =
                /* the pin header uses */
                "P8.11";

        /*
         * Free up the pins used by the cape from the pinmux helpers.
         */
        fragment@0 {
                target = <&ocp>;
                __overlay__ {
                        P8_11_pinmux { status = "disabled"; };
                };
        };

        fragment@1 {
                target = <&am33xx_pinmux>;
                __overlay__ {

                        dallas_w1_pins: pinmux_dallas_w1_pins {
                                pinctrl-single,pins = <
                                        BONE_P8_11 0x37
                                >;
                        };
                };
        };

        fragment@2 {
                target-path="/";
                __overlay__ {

                        onewire {
                                status = "okay";
                                pinctrl-names = "default";
                                pinctrl-0 = <&dallas_w1_pins>;

                                compatible = "w1-gpio";
                                gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
                        };
                };
        };
};

Next, following the document I ran ./install.sh from the debian@ebb:~/bb.org-overlays$ folder which ran DTS on each of the files and then copied them to /lib/firmware and then created a new initramfs. With a few warnings.

update-initramfs: Generating /boot/initrd.img-4.14.94-ti-94
WARNING: Setting CRYPTSETUP in /etc/initramfs-tools/initramfs.conf is deprecated and will stop working in the future. Use /etc/cryptsetup-initramfs/conf-hook instead.
cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p1
cryptsetup: WARNING: could not determine root device from /etc/fstab
'./tools/beaglebone-universal-io/config-pin' -> '/usr/local/bin/config-pin'cape overlays have been built and added to /lib/firmware & /boot/initrd.img-4.14.94-ti-r94, please reboot

Not sure about those errors.

Well it's a warning for cryptsetup, are you using cryptsetup??

At this point I'm guessing the echo > $SLOTS isn't needed since the new dtbo is now part of the initramfs image has it as part of the boot process.

Actually this is for the old "slots" too..

Plugging in the cape and starting up the beagle should theoretically then make a One Wire device available on pin P8.11?

Plug in a debug cable into J1 and dump the U-Boot serial log and we
can find out..

If the DTS file included the definitions from the example BB-CAN0-00A0.dts and the prototype board contained a CAN bus bus driver connected to P9.19, P9.20 would, on power up those pins then be used by the One Wire code and the CAN bus code?

Yes,

Is the difference then that a rebuilding of the initrd image is required for creating custom capes? Is there a short cut?

The initrd is not required for u-boot overlays.

Am I right that this is way more difficult than the echo to $SLOTS since it involves a build and reboot after each edit while developing the custom cape dts file?

No you are incorrect, it's the "same".. In the old days after you
echo a slot, and then decide to "remove it", you'd have to reboot
anyways as the echo 0 would eventually cause an oops..

Again, is there an easier way rather than compiling every single dts file with the ./install.sh script?

./install.sh is just for the lazy, so it does everything, just run

make src/arm/BB-W1-P8.11-00A0.dtbo
sudo make install

Regards,

3

Thanks Robert,

I am not using cryptsetup.

I received my second edition of Derek Molloy’s Exploring Beaglebone and decided to start over from scratch. New MicroSD and latest rev. Work through the chapters from the start setting up as if I was a brand new novice user. Even to setting the device name to ‘ebb’.

debian@ebb:~$ uname -a
Linux ebb 4.14.94-ti-r94 #1 SMP PREEMPT Thu Feb 21 23:29:48 UTC 2019 armv7l GNU/Linux
debian@ebb:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2018-10-07

I was disappointed when I reached page 272 “Flattened Device Tree…” Where his first revision book went into more detail on how to look at devices this revision is just a superficial overview. Net research for the most part, except what I posted below, is all for the old slots approach. Even Derek’s blog on this is from 2016 and hasn’t been touched.

Without a $SLOTS for example, how does one look to see if the cape has been recognized.

You mention uboot serial log? Which one is that and where is it? For the tutorial I am writing I’d like to include what to type and why.

One of the things I’m trying to achieve for this 2GB Beaglebone (and may well be possible) is the ability to power it down and plug in say the Logic Supply CBB-Serial Cape and have it recognize that the CAN bus now uses the pins that were general I/O.

Power down and plug in a different cape like the Logic Supply CBB-Proto which has an EEROM and perhaps a combination of Dallas One Wire(DS1822), SPI (small LCD display) and CAN drivers/devices and that it automatically can capture those pins.
All without having to recompile or rebuild anything.
And my tutorial will take a new user through the process including how to create the information in the EEROM on the cape.
Regards

John Dammeyer

4

DS1822-Python.jpg

So after the ./install.sh and installation of the cape and then power up I do now have access to my DS1822 via a Python app. But another vanishing act, possibly due to the change from the SLOTs approach, is the hex dump below isn’t possible anymore.

debian@ebb:~$ cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C
cat: /sys/bus/i2c/devices/1-0057/eeprom: No such file or directory

So where did the i2c eeprom go? Does the /boot/uEnv.txt need to have i2c explicitly set to access the cape eeproms?

debian@ebb:/sys/devices$ ls
armv7_cortex_a8 platform software tracepoint w1_bus_master1
breakpoint soc0 system virtual

5

A follow up to the request by Robert for the uboot power up information from a terminal connection. It finds the cape. Should I be concerned about the

** Unable to read “/boot/uboot.env” from mmc0:1 **

Or is that just because I’m using the SD card to boot?

Also I’m playing with the little TFT display:

https://learn.adafruit.com/user-space-spi-tft-python-library-ili9341-2-8/wiring

My SLOTs BBB OS version has in the uEnv.txt file

cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
while the tutorial above has
optargs=capemgr.enable_partno=BB-SPIDEV0

and then says to check /dev/ for the spi ports.

"Reboot your device and you should see the files /dev/spidev1.0 and /dev/spidev1.1 now exist."

This slotless version already has them.

debian@ebb:~$ ls /dev/spi*
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1

Is anything else needed then? The Adafruit Tutorial is then also quite dated and will need to have an addendum or be rewritten.

Thanks
John Dammeyer

Here’s the boot up log:

[ OK ] Reached target Shutdown.
[ 4071.826261] watchdog: watchdog0: watchdog did not stop!
[ 4072.180409] reboot: Restarting system

U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **

U-Boot 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: jenkins-github_Bootloader-Builder-65

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **
Board: BeagleBone Black
not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
debug: process_cape_part_number:[BB-W1-P8.11]
debug: process_cape_part_number:[42422D57312D50382E3131]
BeagleBone: cape eeprom: i2c_probe: 0x57: /lib/firmware/BB-W1-P8.11-00A0.dtbo [0x956174f]
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] …
board_rev=[00C0] …
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 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
2148 bytes read in 15 ms (139.6 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.94-ti-r94 …
9724416 bytes read in 628 ms (14.8 MiB/s)
debug: [enable_uboot_overlays=1] …
debug: [enable_uboot_cape_universal=1] …
debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] …
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] …
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb …
loading /boot/dtbs/4.14.94-ti-r94/am335x-boneblack-uboot-univ.dtb …
162727 bytes read in 38 ms (4.1 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] …
uboot_overlays: loading /lib/firmware/BB-W1-P8.11-00A0.dtbo …
1118 bytes read in 318 ms (2.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo …
1440 bytes read in 371 ms (2.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-HDMI-TDA998x-00A0.dtbo …
4896 bytes read in 43 ms (110.4 KiB/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo …
711 bytes read in 288 ms (2 KiB/s)
uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo …
3513 bytes read in 53 ms (64.5 KiB/s)
uboot_overlays: [uboot_detected_capes=BB-W1-P8.11,] …
loading /boot/initrd.img-4.14.94-ti-r94 …
5248133 bytes read in 347 ms (14.4 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet] …
debug: [bootz 0x82000000 0x88080000:501485 88000000] …

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fafe000, end 8ffff485 … OK
reserving fdt memory region: addr=88000000 size=89000
Loading Device Tree to 8fa72000, end 8fafdfff … OK

Starting kernel …

[ 0.002135] timer_probe: no matching timers found
[ 1.012982] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 1.310968] omap_voltage_late_init: Voltage driver support not added
[ 1.318279] PM: Cannot get wkup_m3_ipc handle
[ 1.604702] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: no source widget found for Playback
[ 1.613783] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: Failed to add route Playback → direct → TX
rootfs: clean, 205581/959616 files, 1298256/3888512 blocks
[ OK ] Found device /dev/ttyS0.
[ OK ] Started Serial Getty on ttyS0.

Debian GNU/Linux 9 ebb ttyS0

BeagleBoard.org Debian Image 2018-10-07

6

So it detected your cape and properly loaded the overlay, what's your
problem again?

Regards,

7

Hi Robert,

The problem is the cape was built and tested with the older SLOTs based Debian. Most of the links and books refer to this. Now we no longer have them. So I’m trying to write myself a new user guide so that in 3 months when I’ve forgotten everything I don’t have waste hours sifting through out of date information all over again.

  1. From the command line how do I show which capes are detected since I can’t cat $SLOTS anymore?
  2. This no longer works: cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C

a) How do I find my cape eeprom

b) How do I dump my cape eeprom?
3. Is there something more up to date than this for programming a new cape eeprom or is this still valid.
https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md

if it’s not valid is there a document that is?

  1. There were questions in the previous postings about error messages.

  2. If I write a new dts do I have to
    a) make src/arm/BB-W1-P8.11-00A0.dtbo
    b) sudo make install

c) reboot every time to test this?

That condenses the questions into a simple form.
Thanks
John Dammeyer

8

Hi John,

Hi Robert,

The problem is the cape was built and tested with the older SLOTs based Debian. Most of the links and books refer to this. Now we no longer have them. So I'm trying to write myself a new user guide so that in 3 months when I've forgotten everything I don't have waste hours sifting through out of date information all over again.

1. From the command line how do I show which capes are detected since I can't cat $SLOTS anymore?

1a: cat /proc/cmdline
1b: look at serial boot log

2. This no longer works: cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C
     a) How do I find my cape eeprom
     b) How do I dump my cape eeprom?

This looks like an i2c error, i'll look at this week..

but try, resetting the pinmux..

debian@test-bbb-2:~$ config-pin P9_19 i2c
debian@test-bbb-2:~$ config-pin P9_20 i2c

3. Is there something more up to date than this for programming a new cape eeprom or is this still valid.
             https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md
    if it's not valid is there a document that is?

The original eeprom document has not changed since the 3.8.x era...

4. There were questions in the previous postings about error messages.

But not important enough to restate..

5. If I write a new dts do I have to
    a) make src/arm/BB-W1-P8.11-00A0.dtbo
    b) sudo make install
    c) reboot every time to test this?

Yeap, that's the minimal needed..

Regards,

9
  1. This no longer works: cat /sys/bus/i2c/devices/1-0057/eeprom | hexdump -C

a) How do I find my cape eeprom
b) How do I dump my cape eeprom?

This looks like an i2c error, i’ll look at this week…

but try, resetting the pinmux…

I used the Microsoft Windows approach and shut it down, removed power, and and then powered it up again. (no CTL-ALT-DEL three fingered salute available)

Now it works but it’s changed from 1-0057 to 2-0057. Those folders weren’t there at all before.

I’ve seen this a few times with the BBB. It requires more than one power-boot cycle for some things to take effect.

debian@ebb:/sys/bus/i2c/devices/2-0057$ sudo cat eeprom | hexdump -C
00000000 aa 55 33 ee 41 30 4f 6e 65 57 69 72 65 20 70 6c |.U3.A0OneWire pl|
00000010 75 73 20 43 41 4e 62 75 73 00 00 00 00 00 00 00 |us CANbus…|
00000020 00 00 00 00 00 00 30 30 41 30 41 75 74 6f 41 72 |…00A0AutoAr|
00000030 74 69 73 61 6e 73 20 49 6e 63 42 42 2d 57 31 2d |tisans IncBB-W1-|
00000040 50 38 2e 31 31 00 00 00 00 00 00 00 00 00 00 00 |P8.11…|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|

10
  1. From the command line how do I show which capes are detected since I can’t cat $SLOTS anymore?

1a: cat /proc/cmdline
1b: look at serial boot log

debian@ebb:~$ cat /proc/cmdline
console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet

I then powered down, installed a second cape.

debian@ebb:~$ cat /proc/cmdline
console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=cape-CBB-Serial,BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet

Trial and error for each of the 2-005x folders got me this:

debian@ebb:/sys/bus/i2c/devices/2-0054$ sudo cat eeprom | hexdump -C
00000000 aa 55 33 ee 41 30 63 61 70 65 2d 43 42 42 2d 53 |.U3.A0cape-CBB-S|
00000010 65 72 69 61 6c 00 00 00 00 00 00 00 00 00 00 00 |erial…|
00000020 00 00 00 00 00 00 72 30 31 00 4c 6f 67 69 63 20 |…r01.Logic |
00000030 53 75 70 70 6c 79 00 00 00 00 63 61 70 65 2d 43 |Supply…cape-C|
00000040 42 42 2d 53 65 72 69 61 6c 00 00 07 63 61 70 65 |BB-Serial…cape|
00000050 2d 43 42 42 2d 53 65 72 a0 3e c0 1e 00 00 00 00 |-CBB-Ser.>…|

So one short question:
Why did it change from 1-005x to 2-005x?

Thanks. Now to write up the entire procedure.
John Dammeyer
www.autoartisans.com

11

One other thing. Adding a second cape.

First with Jessie where the Logic Supply cape-CBB-Serial cape CAN device worked but the newest uboot version doesn’t.
The questions are:
Why doesn’t it?
What can I do to troubleshoot this problem?

I suspect it’s because the CAN hardware and can utils are now part of the BBB image. Some sort of conflict with the cape-BBB-Serial and the cape’s eeprom dtbo file linkage that wants the CAN bus pins.

Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-11-06
debian@beaglebone:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.7 (jessie)
Release: 8.7
Codename: jessie

debian@beaglebone:~$ cat $SLOTS
0: P—L- 0 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial
1: PF---- -1
2: PF---- -1
3: P—L- 1 OneWire plus CANbus,00A0,AutoArtisans Inc,BB-W1-P8.11

debian@beaglebone:~$ sudo modprobe can
debian@beaglebone:~$ sudo modprobe can-dev
debian@beaglebone:~$ sudo modprobe can-raw
debian@beaglebone:~$ sudo ip link set can0 up type can bitrate 250000
debian@beaglebone:~$ sudo ifconfig can0 up

And dump the MilCAN messages on the bus.

debian@beaglebone:~$ candump can0
can0 0200800C [2] 85 03
can0 0200800C [2] 86 03
can0 0200800C [2] 87 03
can0 1E601B01 [6] 00 00 00 FF FF FF

12

Because back in 3.8.x days, the i2c bus "#" was a race condition
between the 3 bus node, first got 0, 2nd got 1, 3rd got 2..

The eeprom's are attached to Pins which are attached to i2c"2"...

Thus they are "2"...

Regards,

13

troubleshoot: first let's look at your serial boot log with both
cape's plugged in..

That cape's can port is defined by:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts#L92-L96

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts#L120-L125

I'd expect to see a "can" node just by running

sudo ifconfig -a

I have two of those Logic Supply cape's so i'll take a look at them tomorrow.

Regards,

14

Thank you. That makes sense.

John Dammeyer
www.autoartisans.com

15

One other thing. Adding a second cape.
First with Jessie where the Logic Supply cape-CBB-Serial cape CAN device worked but the newest uboot version doesn’t.
The questions are:
Why doesn’t it?
What can I do to troubleshoot this problem?

troubleshoot: first let’s look at your serial boot log with both
cape’s plugged in…

That cape’s can port is defined by:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts#L92-L96

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts#L120-L125

I’d expect to see a “can” node just by running

sudo ifconfig -a

Yes. I had done that. That’s why I was a bit confused. It appears to be there. I can reboot the Jessie 8.7 and grab the ifconfig from it if that will help.

can0: flags=128 mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 42

can1: flags=128 mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 43

I have two of those Logic Supply cape’s so i’ll take a look at them tomorrow.

One point that may or not be important. Derek Malloy’s second edition uses config-pin -q P1.28 to ask for the P1_28 Mode.
All I get back is

Pin is not modifiable: P1_28

Which suggests his section on CAN (pages 388-394) does not agree with the current BBB Linux version. I did try that with the CAN board not plugged in and got the same result.

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

Here’s the serial boot log.

Regards,
John Dammeyer
www.autartisans.com

[20639.568202] reboot: Power down

U-Boot SPL 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **

U-Boot 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: jenkins-github_Bootloader-Builder-65

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4… ** File not found /boot/uboot.env **

** Unable to read “/boot/uboot.env” from mmc0:1 **
Board: BeagleBone Black
not set. Validating first E-fuse MAC
BeagleBone Black:
debug: process_cape_part_number:[cape-CBB-Serial]
debug: process_cape_part_number:[636170652D4342422D53657269616C]
BeagleBone: cape eeprom: i2c_probe: 0x54: /lib/firmware/cape-CBB-Serial-r01.dtbo [0x296d72f]
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
debug: process_cape_part_number:[BB-W1-P8.11]
debug: process_cape_part_number:[42422D57312D50382E3131]
BeagleBone: cape eeprom: i2c_probe: 0x57: /lib/firmware/BB-W1-P8.11-00A0.dtbo [0x956174f]
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] …
board_rev=[00C0] …
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 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
2148 bytes read in 15 ms (139.6 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.94-ti-r94 …
9724416 bytes read in 630 ms (14.7 MiB/s)
debug: [enable_uboot_overlays=1] …
debug: [enable_uboot_cape_universal=1] …
debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] …
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] …
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb …
loading /boot/dtbs/4.14.94-ti-r94/am335x-boneblack-uboot-univ.dtb …
162727 bytes read in 38 ms (4.1 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] …
uboot_overlays: loading /lib/firmware/cape-CBB-Serial-r01.dtbo …
2135 bytes read in 404 ms (4.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-W1-P8.11-00A0.dtbo …
1118 bytes read in 322 ms (2.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo …
1440 bytes read in 375 ms (2.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-HDMI-TDA998x-00A0.dtbo …
4896 bytes read in 43 ms (110.4 KiB/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo …
711 bytes read in 292 ms (2 KiB/s)
uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo …
3513 bytes read in 53 ms (64.5 KiB/s)
uboot_overlays: [uboot_detected_capes=cape-CBB-Serial,BB-W1-P8.11,] …
loading /boot/initrd.img-4.14.94-ti-r94 …
5248133 bytes read in 350 ms (14.3 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=cape-CBB-Serial,BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet] …
debug: [bootz 0x82000000 0x88080000:501485 88000000] …

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fafe000, end 8ffff485 … OK
reserving fdt memory region: addr=88000000 size=89000
Loading Device Tree to 8fa72000, end 8fafdfff … OK

Starting kernel …

[ 0.002124] timer_probe: no matching timers found
[ 1.011965] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 1.302784] omap_voltage_late_init: Voltage driver support not added
[ 1.310092] PM: Cannot get wkup_m3_ipc handle
[ 1.508531] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: no source widget found for Playback
[ 1.517502] hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: Failed to add route Playback → direct → TX
rootfs: clean, 207358/959616 files, 1303282/3888512 blocks

Debian GNU/Linux 9 ebb ttyS0

BeagleBoard.org Debian Image 2018-10-07

Support/FAQ: Beagleboard:BeagleBoneBlack Debian - eLinux.org

default username:password is [debian:temppwd]

ebb login:

16

Any idea on this yet?

17

P1_x/P2_x = PocketBeagle
P8_x/P9_x = BeagleBone, Black, Green, Wireless, Blue...

So with 4.14.94-ti-r94 I'm seeing this:

sudo depmod -a
sudo update-initramfs -uk `uname -r`

debug: process_cape_part_number:[cape-CBB-Serial]
debug: process_cape_part_number:[636170652D4342422D53657269616C]
BeagleBone: cape eeprom: i2c_probe: 0x54:
/lib/firmware/cape-CBB-Serial-r01.dtbo [0x296d72f]

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[36a476c67f707ba2698bfb30452ebd2951162ce2]
eeprom:[A335BNLT000C1830BBBG0785]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2019-03-03]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2018.09-00002-g08ae12f051]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2018.09-00002-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.94-ti-r94]
nodejs:[v6.17.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20190227.0-0rcnee0~stretch+20190227]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm
eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait
uboot_detected_capes=cape-CBB-Serial, coherent_pool=1M net.ifnames=0]
dmesg | grep pinctrl-single
[ 0.923512] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 0.935203] gpio-of-helper ocp:cape-universal: ready

debian@beaglebone:~$ dmesg | grep can
[ 2.178645] c_can_platform 481cc000.can: c_can_platform device
registered (regs=fa1cc000, irq=42)
[ 2.188942] c_can_platform 481d0000.can: c_can_platform device
registered (regs=fa1d0000, irq=43)
[ 2.779238] can: controller area network core (rev 20170425 abi 9)

debian@beaglebone:~$ sudo ifconfig -a
can0: flags=128<NOARP> mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
txqueuelen 10 (UNSPEC)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device interrupt 42

can1: flags=128<NOARP> mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
txqueuelen 10 (UNSPEC)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device interrupt 43

Regards,

18

Hi Robert,
Alas, unless I typed something in wrong…

debian@ebb:~$ sudo depmod -a
debian@ebb:~$ sudo update-initramfs -uk ‘uname -r’
/boot/initrd.img-uname -r does not exist. Cannot update.

debian@ebb:~$ sudo uname -a
Linux ebb 4.14.94-ti-r94 #1 SMP PREEMPT Thu Feb 21 23:29:48 UTC 2019 armv7l GNU/Linux
debian@ebb:~$

19

`uname -r` : ` = backquote key.. Below escape

update-initramfs:
u = update
c = create

Regards,

20

Hi Robert,
My output doesn’t match yours. Yours didn’t talk about deprecated code.

My system is booting from a 16GB MicroSD card.

A reboot still doesn’t allow me to follow the tutorial in Derek’s second edition and modprobe cannot be found.

Here’s what I did with the correct “`” characters this time.

debian@ebb:~$ sudo update-initramfs -uk uname -r
update-initramfs: Generating /boot/initrd.img-4.14.94-ti-r94
WARNING: Setting CRYPTSETUP in /etc/initramfs-tools/initramfs.conf is deprecated and will stop working in the future. Use /etc/cryptsetup-initramfs/conf-hook instead.
cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p1
cryptsetup: WARNING: could not determine root device from /etc/fstab

debian@ebb:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[38ce81fcdafad0892b6c485acd4e9a2245dfb07a]
eeprom:[A335BNLT00C02716BBBK0E8D]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.94-ti-r94]
nodejs:[v6.16.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20190215.0-0rcnee0~stretch+20190215]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy sudo audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait uboot_detected_capes=cape-CBB-Serial,BB-W1-P8.11, coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 0.989134] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 1.001098] gpio-of-helper ocp:cape-universal: ready
END
debian@ebb:~$ sudo ifconfig -a
can0: flags=128 mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 42

can1: flags=128 mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 43

eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500
ether 04:a3:16:ba:4e:b2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 55

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 896480 bytes 60066400 (57.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 896480 bytes 60066400 (57.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3
ether 04:a3:16:ba:4e:b4 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3
ether 04:a3:16:ba:4e:b7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

debian@ebb:~$