DS18B20 communication

it says:

Yeap that’s old, it didn’t even find the bootloader… Can you share the serial boot log? thru J1 i want to see what u-boot is up too…


bone-log.txt (26.1 KB)

oh yuck!!!

U-Boot SPL 2017.05-rc2 (May 02 2017 - 08:53:40)
Trying to boot from MMC1
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment

reading u-boot.img
reading u-boot.img

U-Boot 2017.05-rc2 (May 02 2017 - 08:53:40 +0530)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
355 bytes read in 4 ms (85.9 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
Booting from microSD ...
reading uImage
9847360 bytes read in 620 ms (15.1 MiB/s)
reading am335x-boneblack.dtb
56827 bytes read in 11 ms (4.9 MiB/s)
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.14.108+
   Created:      2023-12-26  22:17:13 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    9847296 Bytes = 9.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Kernel Image ... OK
   Loading Device Tree to 8ffef000, end 8ffffdfa ... OK

Starting kernel ...

2017 that is old! pre u-boot overlays…

I don’t want to touch it, i’ll probably break your current booting…

Personally, if i was forced into it, i’d go down the direction of using the ‘device-tree-compiler’ command line utility’s to recompile and update the am335x-boneblack.dtb with the onewire node… yuck…

looking at my page here: Beagleboard:BeagleBoneBlack Debian - eLinux.org 2019.04 builds of u-boot around 2020 would be the minimal version for u-boot overlays

Here that old version of u-boot for Debian 9: https://repos.rcn-ee.net/debian/pool/main/b/bb-u-boot-am335x-evm/bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb

wget https://repos.rcn-ee.net/debian/pool/main/b/bb-u-boot-am335x-evm/bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb
sudo dpkg -i bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb

Then you’ll find MLO/u-boot.img under: /opt/u-boot/bb-u-boot-am335x-evm/ Not sure if the install script will work on your image…

BeagleBoard.org Debian Image 2019-08-03

it would be interesting to see what fdisk shows on the partition layout: (8192 is key for newer versions)

debian@26-am335x-bbg:~$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb5001fb9

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *     8192 62333918 62325727 29.7G 83 Linux
debian@26-am335x-bbg:~$ sudo fdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 3.64 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


thanks to feedback, but i’m new to embedded Linux, not sure that i get how to handle this.
Is it possible just to download recent image?

okay, we never know, so i wanted to protect your original data…

Grab either of the (am335x) flashers from: Debian 11.x ( Debian 11.x (Bullseye) - Monthly Snapshot - 2023-10-07 ) or Debian 12.x ( Debian 12.x (Bookworm) - Monthly Snapshot - 2023-10-07 ) to make sure you wipe out the old verison on the eMMC…

For most new users, the minimal or iot is fine, just note very little is installed on the minimal image… (the xfce is really not useful on the am335x).


I thought my BBB boot from micro SD card, not from eMMC, or i’m wrong?

Default boot order is:

  1. eMMC
  2. microSD

So if u-boot on the eMMC is old, it’ll still try to boot files off the microSD but fail.

The ‘usr’ button moves up the microSD up earlier


once i update image to one of these Debian 11.x or Debian 12.x how DS18B20 should be connected (i mean which pin)? Should i make some actions to activate usage of DS18B20 or not?

I’d use P9.12, as there is a pre-built overlay already installed: src/arm/overlays/BB-W1-P9.12-00A0.dts · v5.10.x-ti-unified · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab

So in /boot/uEnv.txt just use:



currently, on my micro SD there are 2 partitions: BOOT and ROOTFS, if i download image am335x-debian-11.8-iot-armhf-2023-10-07-4gb.img.xz, do i need both of these partitions or i can make only one partition and write image to SD?

Use Balena Etcher to write the image to the microSD… https://etcher.balena.io/


after updating BBB image DS18B20 works fine, thanks for support.
My understanding of device tree overlay was correct.
What was my initial mistake? Using outdated image?

Yeah, just an old image.

gotcha, thanks a bunch for support.

Still have some questions:

  1. How to understand that certain image doesn’t support some functionality? release notes?
  2. How come that an old image that i used doesn’t support 1-wire? 1-wire is just an gpio manipulation. This looks like basic functionality.
    While using an old image I loaded 1-wire related modules manually, b/c lsmod says that they are not loaded:
    I used commands:
  • sudo modprobe wire
  • sudo modprobe w1-gpio
  • sudo modprobe w1-therm
    but none of them solve my issue (ds18b20 not detected).
    After update (5.10.168-ti-r72) i run lsmod and see these modules loaded:
    What was wrong with the first approach (load modules manually)?

Your older image, was missing the device-tree modifications needed to use 1-wire.

Today to do those modifications we use “u-boot overlays”, where u-boot will apply the overlay before the kernel loads. Your version of u-boot was to old to properly support the syntax and functionally required.

While you set the values in /boot/uEnv.txt, your version of u-boot did not know what todo with that information.


Hi, i’ve tried to change ds18b20 pin connection and encounter an issue.

My steps:

  1. Create custom .dts;
    BB-W1-00A0.dts (863 Bytes)

  2. Compile .dts and transfer .dtbo from host to BBB;

dtc -O dtb -o DS18B20-P8.46.dtbo -b 0 -@ BB-W1-00A0.dts
  1. Move .dtbo to /lib/firmware;
  2. Edit /boot/uEnv.txt
    enable line:
  1. Reboot.
    After BBB reboot i can see message:

According to it: the pin has been already occupied by some other peripheral (i assume by HDMI controller tda19988).
So, my questions are:

  1. How to disable tda19988 properly or how to use pin P8.46 properly?
  2. Why the message refers to PIN 41 if i’m trying to use P8.46?

Mising: src/arm/overlays/BB-W1-P9.12-00A0.dts · v5.10.x-ti-unified · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab

&ocp {
	P8_46_pinmux { status = "disabled"; };


added the line:
BB-W1-00A0.dts (929 Bytes)
on compile get the error:
Error: BB-W1-00A0.dts:21.5-9 syntax error
FATAL ERROR: Unable to parse input tree