LWN: Comments on "Embedded Linux developers meet for a Yocto project summit"

Embedded Linux developers meet for a Yocto project summit

holgerschurig — Thu, 30 Dec 2010 14:56:35 +0000

Wookey, I'm glad you like OE's design --- because I was part of the design team and many BitBake concepts (e.g. the machine-overrides, gentoo-inspired recipes) are my childs :-) So I indroduced flexibility, but also complexity.

But then your article goes on to speak about Debian on embedded devices. I assume you know that those two things have very different architectures.

Back when BitBake / OpenEmbedded was created, the typical linux embedded device was running on StrongARM or Intel PXA with a mediocre 400 MHz clock or even less. Not to speak about old ARMv4 architecture and bad memory interfaces. This made it virtually impossible to compile something "on the device". Therefore the heckmeck with all this cross-compiling. While cross-compilation is conceptionally and practically way more complex, it allows one to use your fast i386 desktop computer to compile software that will later run on the ARM/MIPS/whatever target devices.

Contrary to this, Distributions like Debian, Fedora or Linux-From-Scratch compile on the i386 for the i386. Or on a MIPS for MIPS. That means you have need some system already running Linux with the same CPU architecture. Then you could use that to bringup your distribution. That complicates bootstrap. Nowadays there's a chance that you just can grab Debian packages for the right architecture and install them on your device, but back than this was a question of luck and chance, especially in the light of possible software, compilation or packaging errors.

Today ARM systems have 600 MHz to 1 GHz (like the Beagleboard). You get them already running with Linux. And suddenly compiling Debian SID packages on the board itself became feasible. That makes it way easier to follow upstream !

Apropos Upstream: this is probably what OpenEmbedded maybe did wrong. OpenEmbedded package makers seldom worked with upstream together (that's now a feeling, I didn't dig out facts about this). For example, an OE developer noticed "Oh, this configure *.m4 script tries to run an arm-compiled test binary while configuring, that won't work. I need to use the host-gcc for it". Then he made a patch, put the patch into OpenEmbedded and it worked. But upstream was not aware of this problem and never fixed the source. On the other side, at this time most upstream projects didn't care about embedded requirements.

I actually used BitBake/OpenEmbedded for commercial products. However, I only used a very small subset of OpenEmbedded. On the final device only about 40 packages got installed. Init-Scripts where different and I used way more from Busybox than OpenEmbedded. For example, OpenEmbedded hat it's own login/passwd and sysvinit utilities, while I used those from Busybox. Taking the good parts of OpenEmbedded in a controlled fashion allowed my company to deliver something that was functional, tested and (internally) well described. OpenEmbedded itself was (is?) a too fast moving target for that. But if you see OpenEmbedded as a repository of great cross-compilation recipes, then you can make quality products with not too much effort out of it.

Embedded Linux developers meet for a Yocto project summit

wookey — Thu, 16 Dec 2010 18:45:12 +0000

I'm like Tim - I always thought the design of OE was good but could hardly ever get it to actually work.

Back is the early days I was part of a project that tried to make a commercial product (the Psion Netbook) on top of OE - which produced a lot of new recipies for OE and some very good work, but ultimately didn't deliver enough to avoid getting canned after the first million or so was spent.

I've spent the last few years seeing how possible it is to make embedded distros out of Debian and mostly learned that anything that strays far from the upstream involves a monstrous amount of maintenance, that package policy is what really defines a distro, and that only reliable mechanism and tested stuff has any longevity and reliability.

I do still like binary-based distros (Like Debian/Ubuntu) for many applications, over source-based ones like OE, but if you want significant divergence from upstream's policy then only source-based will do, and it's a much easier way to bootstrap a new arch than doing it in Debian. I haven't quite yet worked out where Yocto fits in the landscape of tools and distros, but I shall watch with interest.

Embedded Linux developers meet for a Yocto project summit

kbee — Thu, 16 Dec 2010 11:29:59 +0000

I'm just getting into embedded development and know very little about Yocto and how it came to be. However, I wonder if this project can somehow help other embedded distributions like Buildroot or OpenWrt?

I appreciated Andy Green's comments [1] on the FOSDEM talks on cross-build systems [2,3]. It seems like a large effort sink for these distros is private patches against upstream. send-patches.org was to provide a common location for these patches, but it looks like not much is going on. Perhaps Yocto can help with this situation.

[1] http://warmcat.com/_wp/2010/02/08/fosdem-and-the-linux-cr...
[2] http://archive.fosdem.org/2010/schedule/events/emb_cross_...
[3] http://www.send-patches.org/news/20100211-1-FOSDEM-Crossd...

Embedded Linux developers meet for a Yocto project summit

joshual — Thu, 16 Dec 2010 09:48:24 +0000

Build time is an area of improvement for the 1.0 release.

Poky is all about being able to create custom yet reproducible builds, we added a bunch of features in 0.9 to make the system more reliable which ended up costing us in build time.

We'll fix this in 1.0 with better initial build speed through bitbake and pseudo optimisations as well as faster subsequent builds through improved shared state.

Embedded Linux developers meet for a Yocto project summit

hrw — Thu, 16 Dec 2010 08:50:49 +0000

For each of targets which you mentioned you can use Poky/OpenEmbedded. And you will get highly optimized binaries + nice organized sources used to build (for license reasons).

Debian will give you not optimized stuff unless you will rebuild everything which will take you weeks due to "only native builds" requirement.

Ok, you can use Buildroot or write your own system but OE has 7 years now - do you really have a time to solve all problems which got solved by their developers?

And when it comes to UI I agree - Sato does not look impressive. But this is not the only one in OpenEmbedded. You can get GPE, E17, XFCE, GNOME and few other environments working.

Embedded Linux developers meet for a Yocto project summit

oak — Wed, 15 Dec 2010 18:44:20 +0000

Maybe it will add recipes for MeeGo UI stuf?

Embedded Linux developers meet for a Yocto project summit

xxiao — Tue, 14 Dec 2010 19:39:57 +0000

the build alone takes 8 hours on my core2duo/3GB system.
it will be UI-agnostic, the default gnome-mobile UI(sato?) is really unimpressive.

for wireless and router, openwrt fits well. for handheld if you dislike Android/meego you can use poky/OE. for general in-house build you can use buildroot or run-your-own. for high end embedded product you have debian/gentoo, i still failed to see the big advantage of this project, though the more the merrier.

Embedded Linux developers meet for a Yocto project summit

glikely — Tue, 14 Dec 2010 15:28:37 +0000

Oops. I forgot to include Timesys and Renesas in the list of companies represented.