Enabling UART 1 and 2 on Beaglebone Black with Yocto Kirkstone

General Discussion
1

Hello,
I am new to Yocto and trying to get started with the Beaglebone Black. I am trying to enable UART 1 and 2 but I am having no luck. I have tried to follow this thread but was unable to active the UARTs: Enable UART1 in Beaglebone Black Yocto Kirkstone (meta-ti layer) - #19 by apm.

Here is my local.conf file:

This file is your local configuration file and is where all local user settings

are placed. The comments in this file give some guide to the options a new user

to the system might want to change but pretty much any configuration option can

be set in this file. More adventurous users can look at

local.conf.sample.extended which contains other examples of configuration which

can be placed in this file but new users likely won’t need any of them

initially.

Lines starting with the ‘#’ character are commented out and in some cases the

default values are provided as comments to show people example syntax. Enabling

the option is a question of removing the # character and making any change to the

variable as required.

Machine Selection

You need to select a specific machine to target the build with. There are a selection

of emulated machines available which can boot and run in the QEMU emulator:

#MACHINE ?= “qemuarm”
#MACHINE ?= “qemuarm64”
#MACHINE ?= “qemumips”
#MACHINE ?= “qemumips64”
#MACHINE ?= “qemuppc”
#MACHINE ?= “qemux86”
#MACHINE ?= “qemux86-64”

There are also the following hardware board target machines included for

demonstration purposes:

MACHINE ?= “beaglebone-yocto”
#MACHINE ?= “genericx86”
#MACHINE ?= “genericx86-64”
#MACHINE ?= “edgerouter”

This sets the default machine to be qemux86-64 if no other machine is selected:

#MACHINE ??= “qemux86-64”

Where to place downloads

During a first build the system will download many different source code tarballs

from various upstream projects. This can take a while, particularly if your network

connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you

can preserve this directory to speed up this part of subsequent builds. This directory

is safe to share between multiple builds on the same machine too.

The default is a downloads directory under TOPDIR which is the build directory.

#DL_DIR ?= “${TOPDIR}/downloads”

Where to place shared-state files

BitBake has the capability to accelerate builds based on previously built output.

This is done using “shared state” files which can be thought of as cache objects

and this option determines where those files are placed.

You can wipe out TMPDIR leaving this directory intact and the build would regenerate

from these files if no changes were made to the configuration. If changes were made

to the configuration, only shared state files where the state was still valid would

be used (done using checksums).

The default is a sstate-cache directory under TOPDIR.

#SSTATE_DIR ?= “${TOPDIR}/sstate-cache”

Where to place the build output

This option specifies where the bulk of the building work should be done and

where BitBake should place its temporary files and output. Keep in mind that

this includes the extraction and compilation of many applications and the toolchain

which can use Gigabytes of hard disk space.

The default is a tmp directory under TOPDIR.

#TMPDIR = “${TOPDIR}/tmp”

Default policy config

The distribution setting controls which policy settings are used as defaults.

The default value is fine for general Yocto project use, at least initially.

Ultimately when creating custom policy, people will likely end up subclassing

these defaults.

DISTRO ?= “poky”

As an example of a subclass there is a “bleeding” edge policy configuration

where many versions are set to the absolute latest code from the upstream

source control systems. This is just mentioned here as an example, its not

useful to most new users.

DISTRO ?= “poky-bleeding”

Package Management configuration

This variable lists which packaging formats to enable. Multiple package backends

can be enabled at once and the first item listed in the variable will be used

to generate the root filesystems.

Options are:

- ‘package_deb’ for debian style deb files

- ‘package_ipk’ for ipk files are used by opkg (a debian style embedded package manager)

- ‘package_rpm’ for rpm style packages

E.g.: PACKAGE_CLASSES ?= “package_rpm package_deb package_ipk”

We default to rpm:

PACKAGE_CLASSES ?= “package_deb package_rpm package_ipk”

SDK target architecture

This variable specifies the architecture to build SDK items for and means

you can build the SDK packages for architectures other than the machine you are

running the build on (i.e. building i686 packages on an x86_64 host).

Supported values are i686, x86_64, aarch64

#SDKMACHINE ?= “i686”

Extra image configuration defaults

The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated

images. Some of these options are added to certain image types automatically. The

variable can contain the following options:

“dbg-pkgs” - add -dbg packages for all installed packages

(adds symbol information for debugging/profiling)

“src-pkgs” - add -src packages for all installed packages

(adds source code for debugging)

“dev-pkgs” - add -dev packages for all installed packages

(useful if you want to develop against libs in the image)

“ptest-pkgs” - add -ptest packages for all ptest-enabled packages

(useful if you want to run the package test suites)

“tools-sdk” - add development tools (gcc, make, pkgconfig etc.)

“tools-debug” - add debugging tools (gdb, strace)

“eclipse-debug” - add Eclipse remote debugging support

“tools-profile” - add profiling tools (oprofile, lttng, valgrind)

“tools-testapps” - add useful testing tools (ts_print, aplay, arecord etc.)

“debug-tweaks” - make an image suitable for development

e.g. ssh root access has a blank password

There are other application targets that can be used here too, see

meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.

We default to enabling the debugging tweaks.

EXTRA_IMAGE_FEATURES ?= “debug-tweaks”

Additional image features

The following is a list of additional classes to use when building images which

enable extra features. Some available options which can be included in this variable

are:

- ‘buildstats’ collect build statistics

USER_CLASSES ?= “buildstats”

Runtime testing of images

The build system can test booting virtual machine images under qemu (an emulator)

after any root filesystems are created and run tests against those images. It can also

run tests against any SDK that are built. To enable this uncomment these lines.

See classes/test{image,sdk}.bbclass for further details.

#IMAGE_CLASSES += “testimage testsdk”
#TESTIMAGE_AUTO:qemuall = “1”

Interactive shell configuration

Under certain circumstances the system may need input from you and to do this it

can launch an interactive shell. It needs to do this since the build is

multithreaded and needs to be able to handle the case where more than one parallel

process may require the user’s attention. The default is iterate over the available

terminal types to find one that works.

Examples of the occasions this may happen are when resolving patches which cannot

be applied, to use the devshell or the kernel menuconfig

Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none

Note: currently, Konsole support only works for KDE 3.x due to the way

newer Konsole versions behave

#OE_TERMINAL = “auto”

By default disable interactive patch resolution (tasks will just fail instead):

PATCHRESOLVE = “noop”

Disk Space Monitoring during the build

Monitor the disk space during the build. If there is less that 1GB of space or less

than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully

shutdown the build. If there is less than 100MB or 1K inodes, perform a hard halt

of the build. The reason for this is that running completely out of space can corrupt

files and damages the build in ways which may not be easily recoverable.

It’s necessary to monitor /tmp, if there is no space left the build will fail

with very exotic errors.

BB_DISKMON_DIRS ??= "
STOPTASKS,${TMPDIR},1G,100K
STOPTASKS,${DL_DIR},1G,100K
STOPTASKS,${SSTATE_DIR},1G,100K
STOPTASKS,/tmp,100M,100K
HALT,${TMPDIR},100M,1K
HALT,${DL_DIR},100M,1K
HALT,${SSTATE_DIR},100M,1K
HALT,/tmp,10M,1K"

Shared-state files from other locations

As mentioned above, shared state files are prebuilt cache data objects which can be

used to accelerate build time. This variable can be used to configure the system

to search other mirror locations for these objects before it builds the data itself.

This can be a filesystem directory, or a remote url such as https or ftp. These

would contain the sstate-cache results from previous builds (possibly from other

machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the

cache locations to check for the shared objects.

NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH

at the end as shown in the examples below. This will be substituted with the

correct path within the directory structure.

#SSTATE_MIRRORS ?= "
#file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH
#file://.* file:///some/local/dir/sstate/PATH"

Yocto Project SState Mirror

The Yocto Project has prebuilt artefacts available for its releases, you can enable

use of these by uncommenting the following lines. This will mean the build uses

the network to check for artefacts at the start of builds, which does slow it down

equally, it will also speed up the builds by not having to build things if they are

present in the cache. It assumes you can download something faster than you can build it

which will depend on your network.

Note: For this to work you also need hash-equivalence passthrough to the matching server

#BB_HASHSERVE_UPSTREAM = “hashserv.yoctoproject.org:8686”
#SSTATE_MIRRORS ?= “file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH”

Qemu configuration

By default native qemu will build with a builtin VNC server where graphical output can be

seen. The line below enables the SDL UI frontend too.

PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

By default libsdl2-native will be built, if you want to use your host’s libSDL instead of

the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.

#ASSUME_PROVIDED += “libsdl2-native”

You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds

a handy set of menus for controlling the emulator.

#PACKAGECONFIG:append:pn-qemu-system-native = " gtk+"

Hash Equivalence

Enable support for automatically running a local hash equivalence server and

instruct bitbake to use a hash equivalence aware signature generator. Hash

equivalence improves reuse of sstate by detecting when a given sstate

artifact can be reused as equivalent, even if the current task hash doesn’t

match the one that generated the artifact.

A shared hash equivalent server can be set with “:” format

#BB_HASHSERVE = “auto”
#BB_SIGNATURE_HANDLER = “OEEquivHash”

Memory Resident Bitbake

Bitbake’s server component can stay in memory after the UI for the current command

has completed. This means subsequent commands can run faster since there is no need

for bitbake to reload cache files and so on. Number is in seconds, after which the

server will shut down.

#BB_SERVER_TIMEOUT = “60”

CORE_IMAGE_EXTRA_INSTALL += “openssh kernel-modules”

CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to

track the version of this file when it was generated. This can safely be ignored if

this doesn’t mean anything to you.

CONF_VERSION = “2”

Here is my bblayers.conf file:

POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf

changes incompatibly

POKY_BBLAYERS_CONF_VERSION = “2”

BBPATH = “${TOPDIR}”
BBFILES ?= “”

BBLAYERS ?= "
/home/project/Yocto/poky/meta
/home/project/Yocto/poky/meta-poky
/home/project/Yocto/poky/meta-yocto-bsp
/home/project/Yocto/meta-openembedded/meta-oe
/home/project/Yocto/meta-openembedded/meta-python
/home/project/Yocto/meta-openembedded/meta-networking
/home/project/Yocto/meta-openembedded/meta-multimedia
/home/project/Yocto/meta-arm/meta-arm-toolchain
/home/project/Yocto/meta-arm/meta-arm
/home/project/Yocto/meta-ti/meta-ti-bsp
/home/project/Yocto/meta-ti/meta-ti-extras
"

These are the only files I have changed. My meta-ti, meta-arm, open-embedded, and yocto are all from the kirkstone branch. I have tried compiling with machine ?= “beaglebone”, and that generates the BB-UART1-00A0.dtbo and BB-UART2-00A0.dtbo files, but I am unable to apply them in the extlinux.conf file as the kernel says “the fdtoverlays command is unknown”. Using this machine also results in a kernel panic as the root=PARTUUID=${uuid} of the extlinux.conf isn’t set correctly by the build.

When I compile with machine ?= “beaglebone-yocto”, there is no kernel panic, but I cannot use the UARTs. What is the recommended way to enable UART 1 and 2 for the beaglebone black in yocto?

Thanks for your help.

1 Like
2

Go into your existing build and move your downloads folder to a safe place on the NVMe.

Its best to start out with a solid foundatation, the important part to save is the downloads directory and that will save you hours of downloads.

Start over from scratch using the Ti BSP.
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_03_05_02/exports/docs/linux/Overview_Building_the_SDK.html

Setup your metal box, you need an NVMe with at least 500 Gb of free space. Move your swap to NVMe and set it to 60Gb. If you have less than 32Gb ram significantly increase the swap size. In your /conf/local.conf repoint the downloads to your existing downloads directory(full absolute path do not use ~/) outside of your build. Let me know how this is going and I will continue on.

FYI, Ti uses docker and I do not, if you have a specific reason why its important to use docker then it would be appropriate, if not, its a waste. Their current bsp works out of the box with a couple of minor changes during setup.

1 Like
3

Hello,

My previous build was built using Poky instead of Arago. Should I still move the downloads folder and use that for the Ti BSP build?

When I do the Ti BSP build, should I still set the machine to “beaglebone-yocto” or should it be the “am335x”?

Thanks!

4

Yes, you can safely dip out of the downloads.

No.
Use this local.conf. Be careful, make sure you use the one that is in the correct build directory. A couple exist and are for other purposes. This is a fat image, basic dev image that will not fit in emmc. So when you are ready to do serious testing cp this one and just delete everything you don’t need for the project so it will be manageable size for emmc.

This is setup for ipk, unless you have a serious need for .deb packages run ipk.

# CONF_VERSION is increased each time build/conf/ changes incompatibly
CONF_VERSION = "2"

# Where to place downloads
DL_DIR = "${TOPDIR}/downloads"

# Where to place shared-state files
SSTATE_DIR = "${TOPDIR}/build/sstate-cache"

# Build output directory
TMPDIR = "${TOPDIR}/arago-tmp"

# Machine Selection
MACHINE ?= "beaglebone"

# Package Management configuration
PACKAGE_CLASSES ?= "package_ipk"

# SDK/ADT target architecture
SDKMACHINE ?= "x86_64"

# Extra image configuration defaults
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk tools-debug ssh-server-openssh"

# Additional image features
USER_CLASSES ?= "buildstats"

# Disable interactive patch resolution
PATCHRESOLVE = "noop"

# Additional filesystem types (uncomment and customize if needed)
# IMAGE_FSTYPES += "jffs2 cramfs ext2.gz ext3.gz squashfs ubi tar.gz tar.bz2 cpio"

# Parallelism Options (automatically adjusted by BitBake if not set)
# BB_NUMBER_THREADS ?= "4"
# PARALLEL_MAKE ?= "-j 4"

# Distro definition
DISTRO = "arago"

# Terminal command settings
TERMCMD = "${XTERM_TERMCMD}"
TERMCMDRUN = "${XTERM_TERMCMDRUN}"

# Disable mirror tarball generation for SCM repos
BB_GENERATE_MIRROR_TARBALLS = "0"

# Remove old images to save disk space
RM_OLD_IMAGE = "1"

# Enable local PR service for binary feeds
PRSERV_HOST = "localhost:0"

# Enable hash equiv server for improved cache management
BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"

# Build history tracking
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"

# Remove Node.js from image
IMAGE_INSTALL:remove = "nodejs"

#Intall pip3 gpiod after the image is running
#gpiod is not available for kirkstone

# Include additional packages
IMAGE_INSTALL:append = " \
    nano \
    python3 \
    python3-pip \
    libgpiod \
    python3-smbus2 \
    i2c-tools \
    rsync \
    cmake \
    systemd-analyze \
    python3-spidev \
    python3-pybind11 \
    python3-dev \
    libgpiod-dev \
    gcc \
    make \
    sqlite3 \
    dosfstools \
    e2fsprogs \
    libgpiod-tools \
    sudo \
    gdb \
    "



# Disk space warnings
BB_DISKMON_DIRS = " \
    STOPTASKS,${TMPDIR},1G,100K \
    HALT,${TMPDIR},100M,1K \
"

Do a trial run first

$bitbake  core-image-minimal -n

Build

$bitbake core-image-minimal

If you are not into python this is a good time to learn to use it, if you need a package related to python you just $pip3 install. You will not have apt installs after the fact so its best to plan a head and adjust local.conf accordingly.

1 Like
5

in your build, you mention _ipk, i.e. as in the PACKAGE_CLASSES ?= "package_ipk".

Did you ever figure out the build with systemd and deb packaging?

Seth

P.S. I am inquiring because I have built Yocto and Arago on different builds but none of which, lack of practice these days, had a summary or done to completion. What does “package_ipk” offer?

6

Less headaches, all the packages are built from source and some are not easy builds. ipk format is more yocto friendly. That argo build is on systemd, pretty sure, that is in the Ti bsp layers.

7

I have created the build as you suggested. When I upload the image to an SD card and run it on the beaglebone black, it results in a kernel panic.

[ 3.842414] VFS: PARTUUID= is invalid.
[ 3.842414] Expected PARTUUID=[/PARTNROFF=%d]
[ 3.852064] Disabling rootwait; root= is invalid.
[ 3.858273] /dev/root: Can’t open blockdev
[ 3.862645] VFS: Cannot open root device “PARTUUID=” or unknown-block(0,0): 6
[ 3.870606] Please append a correct “root=” boot option; here are the availa:
[ 3.879251] Kernel panic - not syncing: VFS: Unable to mount root fs on unkn)
[ 3.887564] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.80-ti #1
[ 3.893776] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 3.899911] unwind_backtrace from show_stack+0x18/0x1c
[ 3.905198] show_stack from dump_stack_lvl+0x40/0x4c
[ 3.910294] dump_stack_lvl from panic+0x114/0x364
[ 3.915123] panic from mount_block_root+0x140/0x1dc
[ 3.920135] mount_block_root from prepare_namespace+0x158/0x194
[ 3.926185] prepare_namespace from kernel_init_freeable+0x26c/0x280
[ 3.932582] kernel_init_freeable from kernel_init+0x20/0x13c
[ 3.938369] kernel_init from ret_from_fork+0x14/0x28
[ 3.943453] Exception stack(0xe0009fb0 to 0xe0009ff8)
[ 3.948531] 9fa0: 00000000 00000000 00000
[ 3.956748] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000
[ 3.964963] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.971625] —[ end Kernel panic - not syncing: VFS: Unable to mount root f-

When I go into the SD card and change root=PARTUUID=${uuid} to root=/dev/mmcblk0p2, then I can boot without a panic. How can I fix this in the build?

How can I enable UART 1 and 2 with this build? When I try to write to UART 1, I get an error as shown below.

root@beaglebone:~# echo “hi” > /dev/ttyS1
-sh: echo: write error: Input/output error

8

I am not sure why it is missing, I will mount the SD card and get the uuid and use that or you can use a generic path. Some times it works and some times it is blank. Some of those little quirks are extremely time consuming to find. Who ever maintains that BSP might have better insight into that.

Did you load the overlays for the uarts?

Also, use dmesg to see how its enumerated. I don’t recall if S1 is correct.

9

What is the correct way to load the UART overlays? I know the UART device tree overlay files are BB-UART1-00A0.dtbo and BB-UART2-00A0.dtbo, but I’m unsure of the correct way to load these files.

10

Don’t start laughing, its easier to mount the SD card on your metal box and edit extlinux.conf. It does not mount the entire sd card.
I just tried to load the overlays and they are not loading.

U-Boot SPL 2023.04-ti-g2a13324ec63c (Jan 17 2025 - 00:39:49 +0000)
Trying to boot from MMC1


U-Boot 2023.04-ti-g2a13324ec63c (Jan 17 2025 - 00:39:49 +0000)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
Core:  160 devices, 18 uclasses, devicetree: separate
WDT:   Started wdt@44e35000 with servicing every 1000ms (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
<ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:	Arago
Retrieving file: /extlinux/../zImage
append: root=PARTUUID=81fdff7f-02 rootwait rw earlycon console=ttyO0,115200n8,115200
Retrieving file: /extlinux/../am335x-boneblack.dtb
Retrieving file: /boot/BB-UART4-00A0.dtbo
Failed loading overlay /boot/BB-UART4-00A0.dtbo
Retrieving file: /boot/BB-UART1-00A0.dtbo
Failed loading overlay /boot/BB-UART1-00A0.dtbo
Retrieving file: /boot/BB-UART2-00A0.dtbo
Failed loading overlay /boot/BB-UART2-00A0.dtbo
Kernel image @ 0x82000000 [ 0x000000 - 0xc04200 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
   Loading Device Tree to 8ffe4000, end 8ffff305 ... OK
Working FDT set to 8ffe4000



# Generic Distro Configuration file generated by OpenEmbedded
LABEL Arago
	KERNEL ../zImage
	FDTDIR ../
	APPEND root=PARTUUID=${uuid} rootwait rw earlycon console=${console},${baudrate}
	fdtoverlays /boot/BB-UART4-00A0.dtbo /boot/BB-UART1-00A0.dtbo /boot/BB-UART2-00A0.dtbo

Not sure why its not loading.

It does not work with the other variant FDTOVERLAYS either but it is retrieving them. If you cannot get it to work just toss it and use another board vendor. For some reason Ti has omitted the overlays from the docs or I am too old and stupid to find them.

UPDATE: Blame me for the overlay loading issue. Here is the fix and how to diagnose the problem

You can fiddle around with the path in u-boot:

=> printenv bootcmd_mmc0
bootcmd_mmc0=devnum=0; run mmc_boot
=> printenv bootcmd
bootcmd=run findfdt; run init_console; run finduuid; run distro_bootcmd
=> load mmc 0:1 ${fdtoverlay_addr_r} /boot/BB-UART1-00A0.dtbo        
Failed to load '/boot/BB-UART1-00A0.dtbo'
=> load mmc 0:1 ${fdtoverlay_addr_r} ../BB-UART1-00A0.dtbo   
1017 bytes read in 3 ms (331.1 KiB/s)
=> 


U-Boot SPL 2023.04-ti-g2a13324ec63c (Jan 17 2025 - 00:39:49 +0000)
Trying to boot from MMC1


U-Boot 2023.04-ti-g2a13324ec63c (Jan 17 2025 - 00:39:49 +0000)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
Core:  160 devices, 18 uclasses, devicetree: separate
WDT:   Started wdt@44e35000 with servicing every 1000ms (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
<ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:	Arago
Retrieving file: /extlinux/../zImage
append: root=PARTUUID=81fdff7f-02 rootwait rw earlycon console=ttyO0,115200n8,115200
Retrieving file: /extlinux/../am335x-boneblack.dtb
Retrieving file: /extlinux/../BB-UART4-00A0.dtbo
Retrieving file: /extlinux/../BB-UART1-00A0.dtbo
Retrieving file: /extlinux/../BB-UART2-00A0.dtbo
Kernel image @ 0x82000000 [ 0x000000 - 0xc04200 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
   Loading Device Tree to 8ffe2000, end 8fffffff ... OK
Working FDT set to 8ffe2000


root@beaglebone:~# ls /dev/ttyS* /dev/ttyO* /dev/ttyAMA* /dev/ttyUSB* 2>/dev/null
 /dev/ttyS0   /dev/ttyS1   /dev/ttyS2   /dev/ttyS3   /dev/ttyS4   /dev/ttyS5
root@beaglebone:~# cat /sys/class/tty/ttyS*/dev
4:64
4:65
4:66
4:67
4:68
4:69
root@beaglebone:~# echo "Hello UART" > /dev/ttyS1
root@beaglebone:~#

Working extlinux.conf

# Generic Distro Configuration file generated by OpenEmbedded
LABEL Arago
	KERNEL ../zImage
	FDTDIR ../
	APPEND root=PARTUUID=${uuid} rootwait rw earlycon console=${console},${baudrate}
	fdtoverlays ../BB-UART4-00A0.dtbo ../BB-UART1-00A0.dtbo ../BB-UART2-00A0.dtbo
1 Like
11

for extlinux.conf, the fdtoverlay path is in reference to the extlinux.conf file/path, at least that’s what i’ve noticed from different builds.

12

It was around 1 am or better when I did that. Looked at this morning and felt really stupid for not noticing …/zImage that is next to the overlays.

1 Like
13

I just noticed that your u-boot is a newer version than mine. How can I upgrade the u-boot version? Is this the problem?

U-Boot 2019.04-00002-g31a8ae0206 (May 13 2020 - 09:26:17 -0500), Build: jenkins9
                                                                                
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 external warm 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...
14

I have tried the changes you made to extlinux.conf, but I’m running into a problem where it says “fdtoverlays is unknown”.

Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
241 bytes read in 5 ms (46.9 KiB/s)
Ignoring unknown command: fdtoverlays
1: Arago
Retrieving file: /extlinux/…/zImage
12599808 bytes read in 795 ms (15.1 MiB/s)
append: root=/dev/mmcblk0p2 rootwait rw earlycon console=ttyO0,115200n8,115200
Retrieving file: /extlinux/…/am335x-boneblack.dtb
99078 bytes read in 13 ms (7.3 MiB/s)

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ffe4000, end 8ffff305 … OK

Here is my extlinux.conf file. I had to override the uuid to get it to work as mentioned before.

LABEL Arago
KERNEL …/zImage
FDTDIR …/
APPEND root=/dev/mmcblk0p2 rootwait rw earlycon console=${console},${baudrate}
fdtoverlays …/BB-UART1-00A0.dtbo …/BB-UART2-00A0.dtbo

15

That is really odd, your uboot should be the same as mine. I did not change anything major like that since they have tested the BSP.

These are the correct layers.

fred@eng-ai1:~/nvme2/tisdk/build$ bitbake-layers show-layers
NOTE: Starting bitbake server...
NOTE: Started PRServer with DBfile: /home/fred/nvme2/tisdk/build/cache/prserv.sqlite3, Address: 127.0.0.1:36419, PID: 3522700
layer                 path                                      priority
==========================================================================
meta-tisdk            /home/fred/nvme2/tisdk/sources/meta-tisdk  12
meta-arago-distro     /home/fred/nvme2/tisdk/sources/meta-arago/meta-arago-distro  10
meta-arago-extras     /home/fred/nvme2/tisdk/sources/meta-arago/meta-arago-extras  10
meta-arago-demos      /home/fred/nvme2/tisdk/sources/meta-arago/meta-arago-demos  10
meta-arago-test       /home/fred/nvme2/tisdk/sources/meta-arago/meta-arago-test  10
meta-qt5              /home/fred/nvme2/tisdk/sources/meta-qt5   7
meta-virtualization   /home/fred/nvme2/tisdk/sources/meta-virtualization  8
meta-networking       /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-networking  5
meta-python           /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-python  5
meta-oe               /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-oe  5
meta-gnome            /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-gnome  5
meta-filesystems      /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-filesystems  5
meta-multimedia       /home/fred/nvme2/tisdk/sources/meta-openembedded/meta-multimedia  5
meta-ti-extras        /home/fred/nvme2/tisdk/sources/meta-ti/meta-ti-extras  6
meta-ti-bsp           /home/fred/nvme2/tisdk/sources/meta-ti/meta-ti-bsp  6
meta-arm              /home/fred/nvme2/tisdk/sources/meta-arm/meta-arm  5
meta-arm-toolchain    /home/fred/nvme2/tisdk/sources/meta-arm/meta-arm-toolchain  5
meta                  /home/fred/nvme2/tisdk/sources/oe-core/meta  5
meta-arago-bbb-vgi    /home/fred/nvme2/tisdk/build/meta-arago-bbb-vgi  6
workspace             /home/fred/nvme2/tisdk/build/workspace    99

Run this script in the top of the tree.

layer-check.sh

#!/bin/bash

# Set the base directory to the top of the Yocto tree
BASE_DIR=$(pwd)

# Output file
OUTPUT_FILE="$BASE_DIR/bitbake-layers-status.txt"

# Clear the file before writing
echo "BitBake Layers Status - $(date)" > "$OUTPUT_FILE"
echo "=========================================" >> "$OUTPUT_FILE"

# Define directories containing layers
LAYER_DIRS=("$BASE_DIR/sources" "$BASE_DIR/build/meta-arago-bbb-vgi")

# Function to check branch and commit for a given layer
check_layer() {
    local layer="$1"
    if [ -d "$layer/.git" ]; then
        local layer_name
        layer_name=$(basename "$layer")

        local branch
        branch=$(git -C "$layer" rev-parse --abbrev-ref HEAD)

        local commit
        commit=$(git -C "$layer" rev-parse --short HEAD)

        echo "$layer_name: $branch @ $commit"
        echo "$layer_name: $branch @ $commit" >> "$OUTPUT_FILE"
        echo "---------------------------------" >> "$OUTPUT_FILE"
    fi
}

# Iterate through layers in defined directories
for dir in "${LAYER_DIRS[@]}"; do
    if [ -d "$dir" ]; then
        for layer in "$dir"/*; do
            check_layer "$layer"
        done
    fi
done

# Print output file location
echo "Results saved to $OUTPUT_FILE"

If your results don’t match mine you are on the wrong sdk.

fred@eng-ai1:~/nvme2/tisdk$ ./layer-check.sh 
bitbake: HEAD @ 3f88b0052
meta-arago: HEAD @ f59caa5f
meta-arm: HEAD @ 936c02ec
meta-cloud-services: HEAD @ 783826ec
meta-openembedded: HEAD @ 4ad41baed
meta-qt5: HEAD @ 644ebf22
meta-ti: kirkstone @ 41723348
meta-tisdk: HEAD @ 2ee8bea
meta-virtualization: HEAD @ 460ea78d
oe-core: HEAD @ e42b6a40a3
Results saved to /home/fred/nvme2/tisdk/bitbake-layers-status.txt
fred@eng-ai1:~/nvme2/tisdk$

the vgi layer is ours, so it will not be in your line up.

When you installed the sdk what did you use for the oeconfig-file?

./oe-layertool-setup.sh -f configs/processor-sdk/<oeconfig-file>
16

I found that by holding the S2 button when powering on the board, that the correct u-boot is used. My build did have the same u-boot as yours, I was unaware that I hold to hold the S2 button while powering on the beaglebone black to use the u-boot on the SD card instead of the one pre-flashed on the beaglebone. Upon discovering this, your solution for adding fdtoverlays to extlinux.conf worked and I can now use UARTs 1 and 2.

Thanks for all of your help!

1 Like
17

Need to wipe out emmc and write your current bootloader and image to it. The Ti docs have instructions on how to write your image to emmc. Then it will always be on the correct one, that could create major negative event that randomly occurs. That is why these 2 are included in the local.conf dosfstools \ e2fsprogs \