| |||||||||||||
Tools and distributions for embedded Linux developmentTools and distributions for embedded Linux developmentPosted Apr 28, 2010 7:48 UTC (Wed) by tzafrir (subscriber, #11501)In reply to: Tools and distributions for embedded Linux development by warmcat Parent article: Tools and distributions for embedded Linux development
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.
(Log in to post comments)
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).
|
|||||||||||||