Embedded Linux developers meet for a Yocto project summit [LWN.net]

Embedded Linux developers meet for a Yocto project summit

Posted Dec 16, 2010 18:45 UTC (Thu) by wookey (subscriber, #5501)
Parent article: Embedded Linux developers meet for a Yocto project summit

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.

(Log in to post comments)

Embedded Linux developers meet for a Yocto project summit

Posted Dec 30, 2010 14:56 UTC (Thu) by holgerschurig (guest, #6714) [Link]

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.