Why so many BeagleBone boards?

Deltas between various BeagleBones are meant to be handled with boot-time configurations. Sure, there are some large issues existing between AM3358 and AM5729 boards, but the various AM3358 boards should just be handled with different device trees selected at boot.

I’m having issues with kernel modules not being compatible across versions and the result is I need to call all the boards “BeagleBone Black”.

It seems more practical to me to eliminate all the boards and just have “BeagleBone (AM3358-variants with on-board flash)”, “BeagleBone (AM3358-variants running from microSD)” and “BeagleBone (AM5729 variants)”. Just a thought.

Hi @jkrinder :slight_smile:

Before I get too deep into the weeds about naming conventions, can you tell me what problem you’re trying to solve by calling all the boards “BeagleBone Black”? And where do you call them that (using the CLI for a script maybe)? I spent about 30 minutes writing out a big long response about naming, which I still intend to send, lol, but wanted to start by making sure I actually understood the problem you’re trying to solve and that there isn’t something else we need to help with there specifically.


I’d want to call them all “BeagleBone (AM3358)”. The problem is that I have seen cases where kernel modules won’t load on alternate versions based on what board is specified. Realistically, I don’t there should be any differences in BalenaOS.

In my Dockerfile, I do

RUN ./build-kernel-module.sh build --device beaglebone-black --os-version "$VERSION" \
  --src /usr/src/app/linux/hm3301 \
  && ./build-kernel-module.sh build --device beaglebone-black --os-version "$VERSION" \
  --src /usr/src/app/linux/scd30 \
  && ./build-kernel-module.sh build --device beaglebone-black --os-version "$VERSION" \
  --src /usr/src/app/linux/wpanusb

In my startup script, I do

rmmod hm3301
insmod /usr/src/app/output/usr/src/app/linux/hm3301_beaglebone-black_2.65.1+rev1.dev/hm3301.ko
rmmod wpanusb
modprobe atusb
insmod /usr/src/app/output/usr/src/app/linux/wpanusb_beaglebone-black_2.65.1+rev1.dev/wpanusb.ko

If the board is registered with Balena as BeagleBone Black, it works. I’m using BeagleBone Green Gateway and as long as I tell Balena it is BeagleBone Black, it works fine. If I tell Balena it is a BeagleBone Green Gateway, it rejects the module signature (I’d need to search for exact error).

Anyway, I don’t see why you are driving a divide between these boards. They are meant to run the same software as much as possible.


Thanks so much for the additional context.

The reason you’ll see differences like this is because each Device Type we create is based on the versions of U-Boot, Kernel modules, and Yocto BSP’s that are available when we first create it (or make the latest update). These are usually based on customer demand, so not on a particular cadence (yet!). So if the beaglebone-black Device Type was created after the beaglebone green, for example, and thus there was something made available in the kernel that was included in Black that’s not in Green, you might see this. There are a few things to be done about this:

  1. because balenaOS is open source, you are welcome to make PR’s to our code at any time if you notice something out of date or inconsistent
  2. we plan to make that process much easier (as you say, being able to split out some of these components so that they are less directly dependent on each other) in upcoming OS releases
  3. we are also working on making a process by which hardware manufacturers can maintain their own Device Type for balenaOS, so that naming and updates are no longer being bottlenecked by the balena team. We would loved to have done this sooner, but we rather needed to know what tools manufacturers would need first (and go build them), so at least I can say we’re almost there. :slight_smile:

That said, we’re certainly not trying to “drive a divide between boards” so much as make it as obvious a process as possible for someone with limited experience to open up a new board and get it running with balena. Not all of our customers are familiar with the hardware details of their SBCs (some have no idea what an SoC even is), so we try to make it as easy as possible for someone with almost no knowledge of IoT devices to get running. Therefore, someone who doesn’t know what an “AM3358 variant” might be, is not prevented from running a cool app they find on balenaHub using Deploy With Balena (DWB). They see “BeagleBone Black” on the box (or part number in some MFG situations), and that’s what they select in our drop-down for the hardware they’re using.

In some ways I can see why this would go against the nature of BeagleBone hardware (whose goal it is to help educate people about the technology they’re using!) but we also want people to have as smooth of an onboarding process as they can with balena (which is in itself a stack of technology to learn) so it’s in our best interest to make things simple and friction-less wherever we can.

We have considered what you’re describing though, since the SoM / processor is often how hardware manufacturers distinguish their product lines. Unfortunately that’s not always the case, so we have thusfar defaulted to something as human-readable and understandable for anyone as possible. We don’t always succeed, but we do try, and of course are open to feedback.

As I mentioned, we’re in the process of making it much easier for communities of customers and direct manufacturers to support unique hardware with some upcoming improvements, and that involves some consideration to how we expose and name the various Device Types we / they offer. At some point it would be great to have collaboration between balena and BeagleBoard.org Foundation for coming up with a naming convention that makes the most sense for BeagleBoard users in view of the balena platform.

Anyway, all of this is part of a much larger conversation I’d love to have with you about improving the experience for BeagleBoard users on balena; let’s schedule some time to chat soon. :slight_smile: But thank you so much for bringing this up and sharing your thoughts publicly so that others can chime in with their experiences and opinions as well. I hope to hear from others on this thread as well. :slight_smile:

~ Kenna

Hi Jason, indeed we will work on merging as much as possible. When we started supporting different beaglebones I recall there were some issues that made us diverge and supply one image per board. So we created different device types for them. Then the OS could differentiate at runtime and was able to run on multiple hardware but at that point in our platform we could not easily “merge” device types. But now we have added the option for one to “move” a device to a compatible arch device type so that should solve it.
Having said all this, in the near future we’ll be working on doing something in the lines of your suggestions. We’ll need to see how we would name it so that it’s obvious for all people.
Thanks for the input, much appreciated and keep in touch

Florin beat me to an update in this thread, but I thought you’d also be pleased to know that after I responded to you, I shared this with our OS team who collectively told me “I completely agree with Jason”. :smiley: So we’ll be having our next device call May 19th to discuss how this can be accomplished (as Florin mentioned), and I’ll keep updates going here for everyone’s benefit.

Quick update! We’ve had our internal call and agreed that it would be best to categorize our underlying Yocto machines by SoC, while maintaining user-friendly device names in our UI. Our next step is to discuss this in an Product call next week (effectively to decide how we can do this and not break other things) after which I’ll provide another update in this thread for those following. :slight_smile: