[manuel_w]

Since an embedded Linux system will likely require use of either Buildroot or Yocto, I'd like to ask the following slightly off-topic question:

Which SoM product line would you say has the best vendor support? I'm talking about quality of the BSP (board support package). (A meta-layer, in Yocto terms.)

Raspberry Pi has quite a community behind it, so meta-raspberrypi has a number of contributors. (None of which payed by the Raspberry Pi foundation, though.)

My latest project involved a NVidia Jetson SoM, and I was surprised to learn that the BSP doesn't see any support from NVidia at all. They rely on one motivated guy (Matt Madison) maintaining it in his free time.

I'd love to see a vendor that provides a first-class BSP maintained by their own people.

[aquilum]

Disclosure: Raspberry Pi employee, focussed on better tooling for people building products with Raspberry Pi devices.

--

Raspberry Pi provide pi-gen (https://github.com/RPi-Distro/pi-gen), which allows you to build a customised Debian-based OS that uses our package list to get updates as we release them, with a low impedance mismatch between developing your software on Raspberry Pi OS and your deployment platform. Since it's debian based, your resultant system winds up being _very_ familiar.

We also provide tooling that compliments pi-gen. For example, rpi-sb-provisioner (https://github.com/raspberrypi/rpi-sb-provisioner), which will happily ingest an OS image created by pi-gen and automate the configuration of signed boot with an encrypted rootfs on CM4 devices. I've used it to flash half a dozen Raspberry Pi devices in rapid form as part of testing, and it runs on our own hardware.

I'd love to see what people make of these tools, and where we could expand support / docs / ascii-art. I don't check HN very often - but I'm pretty responsive to Github issues.

[candiddevmike]

> Since an embedded Linux system will likely require use of either Buildroot or Yocto,

I don't know if that's the case anymore. The kernel ships with a lot of drivers now, and Root FS for embedded devices aren't really space constrained anymore. The needs of an IoT device have also grown to include things like containers and telemetry. In my experience, forking off of an existing distribution like Debian is way easier than navigating Buildroot or Yocto's documentation and cruft, and results in faster builds.

I got so fed up with those tools I eventually built a custom tool (Etcha) to build my own meta distribution (EtchaOS) of immutable variants for Debian, Fedora, etc. It owns the entire provisioning pipeline and builds multi-arch images in less than 10 minutes:

https://etcha.dev/etchaos/explanations/build-process/

[rkangel]

For the projects I've done, we're not usually particularly space constrained, but we are usually at least one of:

* Cost constrained so RAM constrained * Need fast boot times * For a niche processor architecture

Starting with very little apart from an init system and busybox and then building up from there has been a good approach to get the performant (by whatever metric) platform that I need.

That said, I'm not a fan of Yocto at all. I find it painful and slow to work with. I experimented with using Nix (as in NixOS) as my build platform which had some great advantages (e.g. great caching of build steps), but also some pain.

[mschuster91]

> For a niche processor architecture

It's been ages since I've last seen something else than ARM and x86 - are people still bringing up new designs for MIPS CPUs?!

[nrclark]

unrelated but curious - what do you think of OSTree-based embedded distros? Any future in it?

[candiddevmike]

I see it as an overly complicated way of trying to apply containerization concepts to a base OS via transactions. It's really hard to use OSTree on new projects or get existing distros like Debian to work with OSTree. I think the update process, while in theory should be better, ends up being a black box of will it/won't it frustration for end users.

Finally, OSTree is mainly a Red Hat thing and is built for their needs (CoreOS). They could pull the rug on it in the sense that what you build today using it may not work tomorrow if Red Hat needs OSTree to function differently. Which is their perogrative, as they are the primary contributors to it.

[hda111]

What do you think about using btrfs snapshots instead of ostree similar to openSUSE MicroOS or SLE Micro?

[dgfitz]

One that comes to mind: https://github.com/nxp-imx/meta-imx

I have done quite a bit of yocto work at $dayjob, and having a vendor-supported upstream BSP is (usually) really pleasant to work with.

[fullstop]

Yes, NXP's Yocto support has been fantastic.

[nrclark]

Agreed, NXP does a good job with their yocto layer.

[ehaskins]

I have current products using raspberrypi and i.MX parts, and have worked with teams using TI and Renesas parts. Some fully custom boards, some SoM based.

Their BSPs all suck to different degrees, but you can work around the issue with enough effort. If I had to choose ignoring cost, I'd pick an i.MX part, but they're priced for the industrial consumer where price isn't a big concern.

Stay away from any asian parts (Allwinner) or phone parts since they seem to have no vendor or community support.

Like others have said, some of the SoM vendors do a pretty decent job of hiding the evil, but that often comes with very opinionated BSP layers which limit your product design. We've had to ignore/replace all of our SoM vendor's layers, borrowing the few useful parts as needed.

[cjk]

FWIW, some of the Allwinner stuff has fairly robust support in mainline Linux, and there are ongoing efforts to upstream missing bits: https://linux-sunxi.org/Linux_mainlining_effort

No vendor support is probably accurate, though.

[AlotOfReading]

NXP is probably the best "big" vendor for this. The main issue is that their documentation solution/website is awful.

I think a smaller vendor like Toradex is more in line with what you're asking for though. I haven't used them myself, but I've heard very good things. First class yocto support is a core part of their offering.

[phlipski]

The Toradex's, Phytec's, Boundary Devices, etc... of the world all do a decent job with their BSP's but just know that they pull from NXP's mainline BSP release so there is a lag in time from when NXP makes a new release. Sometimes they'll fork their own libraries which I've seen cause some problems with application level software from NXP.

[m-ee]

I’ve been happy with toradex. Boundary is another similar company but haven’t used them.

[graymatters]

Avoid nvidia if you can. Their attitude towards anything Open Source has been extremely unsupportive if not outright shitty. Part of company philosophy.

[throwway120385]

I've been getting a lot of traction over the past 10 years with Debian multistrap and just the kernel from the BSP. I've never needed Buildroot or Yocto.

[cbsks]

I recently got an Nvidia Orin Nano to play with and found Nvidia’s BSP to be very well documented and easy to use… but I haven’t looked into using Buildroot or Yocto directly. https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide...

[phlipski]

Yocto is overkill for a hobbyist. It's designed to help big companies build linux distributions for multiple platforms. It works great for companies like NXP that have the resources to devote to it, but it's a f&$cking bear to wrap your hands around if you just want to build linux for a single dev-board.

Buildroot is much smaller/simpler for hobbyists IMO.

NVidia's Jetson lineup is really a double edged (disingenuous IMO) sword. They provide some nice GPU/NPU power for AI stuff and a decent price and is great to play/learn with. However if you want to take a jetson to production you can't. They don't sell the bare SOC's and the modules have limits to how many you can buy. That jetson lineup is probably a 0.05% pimple on their balance sheet...

[blueflow]

RPi has a nice community, but some of its drivers still set TAINT_CRAP on Linux.