Jason,
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:
- 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
- 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
- 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.
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. 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.
~ Kenna
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.