Has BeagleBone Black been abandoned?

Q

QuesoGrande

I am looking for a small SBC for some control work which needs a fairly large number of GPIO pins. BeagleBone Black looked like a good candidate, but it appears to have been abandoned by FreeBSD. Is this observation correct or is there still development ongoing? If ongoing, what is the current state of the development?

Thanks,
QG
 
It does look like the Beaglebone U-Boot port has not been maintained.
Look at the package message and look at the directory.

Code: 
/usr/local/share/u-boot/u-boot-beaglebone # cat README
U-Boot loader for BeagleBone and BeagleBone Black.

To install this bootloader, copy the files MLO and bb-uboot.img to the FAT
partition on an SD card or the eMMC.  Normally this is partition 1, but
different partitions can be set with U-Boot environment variables.

This version is patched so that:
 * API features are enabled.
 * A boot.scr (U-Boot scripts ) that loads ubldr.bin and execute it is included

For information about running FreeBSD on BeagleBone or BeagleBone Black, see
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone

But look at the files:

Code: 
/usr/local/share/u-boot/u-boot-beaglebone # ls
MLO        README        metadata    u-boot.img



You could also build Beaglebone images with Crochet or Poudriere Image.
github.com

GitHub - freebsd/crochet: Build FreeBSD images for RaspberryPi, BeagleBone, PandaBoard, and others.

Build FreeBSD images for RaspberryPi, BeagleBone, PandaBoard, and others. - freebsd/crochet
github.com github.com
 
The Armv7 images does contain many Beaglebobe DTB.

am335x-bone.dtb
am335x-boneblack-wireless.dtb
am335x-boneblack.dtb
am335x-boneblue.dtb
am335x-bonegreen-wireless.dtb
am335x-bonegreen.dtb
am335x-pocketbeagle.dtb
 
Well, this is rather coincidental as I had the same question a few days ago and I figured I could spend some time away from my usual worries.

The short story as far as I gathered:
Due to device tree changes - which are imported from the Linux kernel tree and are maintained by TI - which weren't yet implemented in FreeBSD, the AM335x support had declined to a point it no longer booted. After that the necessary drivers were removed from the GENERIC (armv7) kernel to prevent issues and maybe compilation errors.
There is a page on the wiki which talks about several patches (for CURRENT - FreeBSD 15) which are currently in review to make it boot again.

Like I said, a few days ago I posed myself the same question and checked if I could get it to boot again with these patches and surely, it does. The catch is that you'd have to apply these patches to your local source tree including resolving any conflicts, then create your own image from said source tree. This is rather easy, but does take quite a while.
As it happens I already triaged them and applied them to the stable/14 sources with some compilation fixes. Most likely the same commits can be applied to the current 14.1-RELEASE (or with very minor changes) but I haven't tested this myself. By the time I finish up my experiments we'll probably be at 14.2-RELEASE.

If you're impatient you can check out a filtered stable/14 branch from my github (meaning: I removed a commit which doesn't compile from my stable/14). I've just rebased it, but 99% certain it should still compile. Note: I take NO CREDIT for the patches. Much smarter people have written and (partially) reviewed these fixes.
For those who want to create an image from that (or any other src) tree: sh release/release.sh -c release/arm/GENERICSD.conf and then be very patient.
Cherry-picking the same fixes onto releng/14.1 should be rather feasible as well, if 14/stable is too experimental for you.

As far as testing goes: my BBB is currently building its own kernel just to ensure everything is working well and it's been doing so without issues but rather slowly :)
 
Apparently I left that one non-compiling commit on the branch I pushed to Github specifically to remove it ... it was late I guess. I modified that. IF someone has checked it out already, it can be removed by doing git reset --hard 1ce543d5cba127711033ba07e6eebdffb7dd22fa (hash of "D46723: clock reworks")

Also note that somehow Github reports it was based of of the main branch (missing 1000s of commits) instead of stable/14, not sure how I can fix that display. It doesn't really matter but it does annoy me slightly.

And lastly: building a kernel locally took 5h+ (GENERIC) or 6h+ (GENERIC-DEBUG).
 
You must log in or register to reply here.
Back
Top