| |||||||||||||
Tools and distributions for embedded Linux developmentTools and distributions for embedded Linux developmentPosted Apr 27, 2010 19:31 UTC (Tue) by warmcat (guest, #26416)Parent article: Tools and distributions for embedded Linux development
I certainly agree with your conclusion that prebuilt, packaged OSes are going to be the future, but you missed something interesting.
Most of the distros you mentioned are cross-built which has quite some costs associated with it for a large packageset.
Fedora on ARM
https://fedoraproject.org/wiki/Architectures/ARM
has been available for over a year now and has a native-build approach.
Since its (yum) repos provide a large package universe already, typically you are only into native-building your own packages on top of the distro that's specific to your device; there's no need to build the bulk of the packages you use.
Increasingly the glue between a stock rootfs package set and the specialized device function is being done in interpreted scripting languages which also goes to make the developer build action redundant.
Quality of the results is also critical; Fedora provides really high quality packages prebuilt.
(Log in to post comments)
Tools and distributions for embedded Linux development Posted Apr 28, 2010 7:48 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
Emdebian, that is mentioned there, is also for this mode of operations.
Indeed Emdebian Grip strives to maintain compatibility with the rest of the Debian archive. There should be no issue in mixing packages from Grip and original Debian packages.
Tools and distributions for embedded Linux development Posted Apr 28, 2010 8:04 UTC (Wed) by warmcat (guest, #26416) [Link]
> Emdebian, that is mentioned there, is also for this mode of operations.
Sure, I actually use Fedora on ARM so I noticed it missing. I'm sure people would also get a good experience with Debian based stuff from the same principle.
A lot of people are still in the mindset that because it's embedded you have to cook everything yourself and minimize footprint and so on; that mass build mindset pushes them towards cross.
That is still required for weaker chips but it's now common that ARM-based chips are more than strong enough (say, 400MHz ARM9+; Cortex A8 and 1.2GHz Marvell chips are now in real devices) and have enough resources to host their own build. In the case you're using a normal distro, you don't care much anyway because you just use the packaged binaries for almost everything same as you would on a desktop.
I found it's a real breakthrough to be able to look at the embedded device same as a - in my case - Fedora server or desktop device and manage it by yum, have full bash, sysvinit if you want it, all the full strength servers. If you have the appropriate CPU and storage - I have SD Card rootfs on my devices - then this tradeoff can be a huge advantage in quality and time to market.
Tools and distributions for embedded Linux development Posted Apr 28, 2010 9:23 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
There's a different limitation: disk space.
I have a nice little SheevaPlug based on the same Marvell CPU you mentioned. It's an ARM device with 512MB of RAM and 512MB of flash. That CPU and 512MB of RAM is more than enough for for building. But 512MB of flash is practically nothing if you also want to keep a build environment around.
I actually run it from a 4GB SD card. This gives a bit more space for a build system, but still, not as much as I'd like.
Being able to build packages on a stronger x86 system I have around is also useful.
Tools and distributions for embedded Linux development Posted Apr 28, 2010 14:19 UTC (Wed) by zlynx (subscriber, #2285) [Link]
If you have networking you can always use NFS.
Tools and distributions for embedded Linux development Posted Apr 29, 2010 11:36 UTC (Thu) by warmcat (guest, #26416) [Link]
> I actually run it from a 4GB SD card.
I can absolutely recommend that approach... unlike the on-PCB flash you can put a normal filesystem on it (we use ext4 with great results) and you can upgrade it any time, 16GB SD Cards are now available and 32GB will be along soon. You can pop it out and use on a host via SD slot as well.
On the device I am working on we go a bit further and do true SD Card boot (the bootloader is on the SD Card, ROM on the CPU fetches and runs it) which has the advantage the whole this is unbrickable.
BTW for Fedora, we use a 2GB root partition to hold all the -devel and rootfs files and it's enough for our purposes so far.
Tools and distributions for embedded Linux development Posted May 6, 2010 14:31 UTC (Thu) by dominosrob (guest, #63549) [Link]
From what I've read the write speed performance of the SD card will gradually degrade due to the lack of a TRIM function. This has become a big enough issue that Windows Vista and newer Linux kernels utilize the TRIM function on SSD drives that support it. But this function has yet to be put on SD cards (probably cause their designed for digital cameras!)
NAND flash may be better suited since the wear-leveling is integrated into the filesystem software (Flash Translation Layer).
Tools and distributions for embedded Linux development Posted Apr 29, 2010 11:06 UTC (Thu) by eru (subscriber, #2753) [Link] Most of the distros you mentioned are cross-built which has quite some costs associated with it for a large packageset.Based on my experiences (which involved cross-building on Linux for a funny embedded BSD-derivative), by far the biggest grief with cross-building was that most packages use "autoconfiguring" that pokes around the build environment and assumes the target is the same. Software with the old-school "manually edit the makefile and then build" approach is much easier to deal with. Another source of frustration was build processes that create binaries and then run them as part of the building. Software projects could make things much easier for cross-builders by avoiding the abovementioned things. Linuxes are now so like each other that a makefile with no autoconfigure step would work in most cases. at least is should exist as an alternate build method.
Tools and distributions for embedded Linux development Posted Apr 29, 2010 11:32 UTC (Thu) by warmcat (guest, #26416) [Link]
> by far the biggest grief with cross-building was that most packages use "autoconfiguring"
Right I also spent a lot of time getting a few dozen basic packages to crossbuild in the past (good luck with perl!), that's part of the reason I am such an enthusiastic convert to native build approach.
The autoblah stuff did get better over time, if the project came ready to work with newer autoblah it was possible to inform ./configure that you were building cross and it might even take care of most things. A lot of projects come with their own build approaches, eg webkit, sometimes they can be coerced into doing cross but each time it's a new different mountain to climb to understand exactly "how".
Native build eliminates all that and you can just do ./configure again because you're not having to trick anything. Combined with realizing you don't have to put up with cut-down anything any more like busybox ash vs actual bash, most of the special-case magic about "embedded" disappears and it's like working on a normal box with corresponding smoothing of development process and increase in dev speed.
yum RAM requirements Posted May 4, 2010 18:47 UTC (Tue) by hollis (subscriber, #6768) [Link]
I have one of the original Kuroboxes: basically PowerPC 603e with (non-upgradeable) 64MB of RAM. I tried to use Fedora, but after going through an agonizing process of actually installing it, I discovered that yum needed at least 128MB (don't remember the exact number now). :(
|
|||||||||||||