Has Ti dropped support for BeagleBone Black in Yocto

We might be on different pages on this, set up gtkterm to interface with the TTL/USB on debug port. Do this before you power up the board, turn logging so you will have a transcript of the entire boot sequence. Look that over and see what is hanging or what error messages are present.

Yes, us too.

Seems like you have your hands full with this project, we go down the simple path. I just use the RCN recipe to build images, it works flawlessly for us and provides a solution for what we need to do with the boards.

@foxsquirrel I tried to send a reply last night, but it wouldn’t let me post more messages, so I tried deleting a couple, but it still couldn’t let me post more than 3 in this thread. I think I may have been moved up to basic.

I found a Debian 9.9 marked for the AM4335x that reliably boots and brings up X, has all the Qt libs on it, but it’s all older and I’m trying to get the latest Qt 5.15.x, the version from the following page is Qt 5.7 I believe. I can successfully burn an SD that I can insert into the SD slot and boot from it reliably. I must be compiling something incorrect in the current yocto. There may be a mismatch with Qt, I don’t know.

So this tells me I have one of 2 problems.

  1. boot is incorrect on the BBB
  2. wrong machine type

I am using beaglebone-yocto as the machine type which is the correct type, AFAIK. It has the correct am335x-boneblack.dtb on the /boot partition, so I think it is setup ok.

https://beagleboard.org/latest-images

Suffice to say, this is a yocto problem, not the hardware of the BBB, or that image wouldn’t be able to burn/boot reliably.

Just as a follow up to this thread. I have determined that my BBB wasn’t able to boot from the NAND so it couldn’t boot the SD, and because of that it would re-write the SD. I currently have a non-GUI image from beagleboard.org which is to flash a 4gb BBB.

As long as the NAND is flashed properly it can boot, so I have Debian 9.9 on my NAND currently.

More importantly is which device tree, uEnv.txt, MLO cp’d to the 1st partition.

I have images I’m building from the github buildroot repo which are from 02/2023 in the /etc/os-release.

PRETTY_NAME=“Buildroot 2023.02-git”

My image is not complete as it start Xorg but nothing displays on the HDMI of the BBB, and I"m still missing a lot of the Qt5 tools, but I have current Qt 5.15.8 on my image.

1 Like

RE: Yocto, with the proper NAND image

I can now boot my image with Qt 5.15.7/zmq/sodium in /usr/lib, very sparse shell using meta-openembedded/meta-oe and meta-qt5 both from github.

1 Like

Make sure you have the HDMI overlay in you boot file.

Nice…

I am new person w/ Yocto and OpenEmbedded along w/ Poky builds.

I have built it before but not to success of porting it to the BBB. Commending natures to you, sir.

Now, I think I may have a chance outside of kirkstone.

Seth

silver,

The one piece of advice I can offer you with Yocto is to create you own meta-xxxxx layer that you will use for your local changes. All depends on what you need to do, but having a meta-layer of your own goes a long way to append any of the existing recipes. I work in Yocto more often than I do buildroot, but buildroot has some advantages to using it also.

There does seem to be some type of transition from old firmware/u-boot to a newer version that works with the current repositories. At minimum you should pull the latest repo head off github. Set your first goal to build and boot the image on the BBB.

The BeagleV project kinda points that out on the home page of that forum here.

Alan

1 Like

@softorchestra ,

I think the version of u-boot needs to be newer compared to the kernel getting pulled.

…

If I am wrong, someone jump in and tell me.

I have only been successful in building w/ Poky twice so far and both were w/ kirkstone.

Buildroot is another story. I got as far as WiFi for the BBBW and bailed. Issues w/ too much fun or something.

Anyway…I can now look back and say what you told me, i.e. make a meta-layer of my own for building.

Seth

Seth,

In the past I was able to build on kirkstone, just a few months ago, as well as hardknott and honister, but the BSP was an IMX and in that case NXP provides much of the integration…however kirkstone is getting a bit dated and I’m building on langdale currently which is the most recent.

The meta-layer is not needed in some cases, if you can make local changes and not have to push upstream. As long as you keep your changes in a meta-layer of your own, you can keep fetching those upstream repos like meta-poky and meta-openembedded. Those are the main ones, but you definitely need meta-openembedded as that is where the device trees reside for the BeagleBone Black.

There is a separate one if you want to use wifi.

work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-bone.dtb
work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-boneblack-wireless.dtb
work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-boneblack.dtb
work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-boneblue.dtb
work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-bonegreen-wireless.dtb
work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-bonegreen.dtb

Alan

1 Like

I just reread what was stated here…

And…oh. So, it is located in work/beaglebone_yocto-poky-linux-gnueabi/u-boot/1_2023.01-r0/build/arch/arm/dts/am335x-boneblack.dtb

This is grand news. I never knew it existed. Hence, a new person at it.

At times, I just build blindly. As the docs. get more in depth, I seem to miss a lot.

Reviewing them over and over is needed for me or anyone else who has the aloof mentality. Thank you for your words.

Seth

P.S. Kirkstone is dated. Got it. I will try langdale in my next blind build. Who knows? I can probably use what you have taught me as a base instance and move forward. I see the links you posted. Thank you again…

2023.01 is a very recent u-boot. I can only think for now what exactly is invested in that specific u-boot.

Oh!

How many GB do you think it will take up? 25 GB?

Seth

Seth,

I just wanted to make very clear that using the BBB to prototype can still be accomplished by pulling the layers one needs from the proper sources. The BeagleBone is one of the few open hardware platforms, although there may be some freescale designs floating around. My love for UNIX/Linux comes out of my hatred towards ms software and practices in general. Those are old bridges…

Most of the companies charge thousands to provide an early prototype of a hardware development board, like the NXP.

It just so happens that my current client is developing for the AM335x chip, so it needs to be the black or white. I haven’t used my BBB or PIs until 3 or 4 months ago, they all sat for about 10 years. About 5 years ago I ported Crossmatch’s fingerprinting SDK to the Raspberry PI II/III, it wasn’t too hard as they had a Linux port I did for them. I think it’s entirely possible to use the BBB for prototyping embedded systems, and the huge advantage with yocto is that you can change the architecture by editing the MACHINE type. The only real disadvantage of using yocto is the build time for the 1st build. Developing inside of the bitbake environment always seems to be a time sync to me, but I really like having the source for EVERYTHING. I have long learned that having the sources will enable one to fix a bug. Buildroot seems to pull a lot of pre-built binaries, yocto is more how open source should be, IMO.

1 Like

Alan,

Being open and all here…

  1. I am building?
  2. I will update you soon!
  3. Motors are fine and dandy w/ me but…
    a. I can only program other peoples’ achievements so long…
    b. I need to figure out how to do things on my own
    c. I may have figured a bit but not enough yet!

Seth

P.S. But right about Yocto bitbake taking forever for the first go around… I think the main, like you say, reason to use Yocto is having full “authority” over the processes that may take place or that will take place.

Update

recipes-devtools/gcc/gcc-crosssdk_12.2.bb:do_compile will not build.

I think I am missing something. Dang it.

Seth,

You’re most likely missing a package on your development host.

What version of Linux are you using?

This is for Ubuntu 22.04 (Jammy Jellyfish)

(you can copy/paste if you have sudo installed)

sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib
build-essential chrpath socat cpio python3 python3-pip python3-pexpect
xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa
libsdl1.2-dev pylint xterm rsync curl zstd

Alan

1 Like

You are right…I skipped the update/uprade/apt install before building. Ecstatic and not astatic…

Sheesh.

Seth

P.S. Thank you, sir. Oh and I am using WSL2 on a Debian Distro. Sorry to admit to it.

Seth,

I had a project I was going to use the BBB for, which used a Xbee wifi, I wanted to create a public mesh where cars could propagate the signal distance and you could have them inside your home to automate lighting and condition.

Yocto does require an investment in time to build that mammoth the first time, but there are man years of work inside the frameworks and software that allows people to do that.

But the ease of changing an architecture makes it pretty easy to use on multiple projects, so IMO the investment does pay off. I’ve used many processors for embedded, powerpc, mips, atom, arm and all it’s variants…nowadays almost everything is arm being cross developed on an x86 host.

Some folks who are more hardware oriented typically use RedHat/Fedora as their development hosts, where software oriented people like me tend to use Ubuntu/Debian. Understanding the difference is key, IMO.

I was sent a brand new BBB from my client. It is made in China now. If you go to the BeagleV forum they mention something about the SoC being manufactured by a different vendor.

All that said, I would say that the Raspberry PI was always just a tad easier to get all the peripherals working on it over the beaglebone. Maybe that’s an illusion, but it seems so to me.

Alan

Alan,

I am building the core-image-sato for the ext distro now.

Since my fail to install the prerequisites, the cross compiler did not do its duty.

Seth

P.S. Thank you. I looked in the docs. of Yocto for the build tools needed. I was unable to figure out what was needed outside of zstd and another tool for whatever reason.

I bought some from Digi-key that are built in the USA.

https://www.digikey.com/en/products/detail/ghi-electronics-llc/BBB01-SC-505/6210999

Had one of the other manufactures board that died, no blue light. So, bought some of these and all are still running.

Seth,

That’s half a distro in reality. The WSL is a POS, no, it’s a piece of royal $#!T…it doesn’t package properly.

It does compile Yocto as my previous client was forcing the developers to use it. I hate it. Nothing works correctly, and git is in some shells and not others…command prompt may have it and powershell may as well…there’s a kinda strange thing where the windows glue layers are a bunch of porked up overhead. The imx8 I was building on Ubuntu took me 3-1/2 hours for a full compile, 6-1/2 hours in WSL2.

I have some great Gates/Balmer stories…I had created one of the largest user groups in L.A. in the late 80s, but eventually me and ms split our ways and I went with IBM and supported my family with OS/2 for about 10 years…probably a bad mistake in my career, but I’m fine with having been a consultant.

Yocto will bring a windows machine to it’s knees quick.

If I need to use Windows I demand the client sends me a machine with a Windows license on it, I refuse to buy one…

Alan

1 Like

wsl takes forever…

I had to start over. The build was missing some dependencies. glibc would not build. Blah.

Seth