Re: how to emdedded ramdisk.gz in vmlinux for linux-2.6.14?

[Marc Karasek <marckarasek@ivivity.com>]

Basically due to design issues and cost issues having a flash based
system is not possible.  Currently we have only 16MB total of flash and
the biggest contiguous block avail in this is only 12MB.  Our current
ramdisk (uncompressed) is running at 30MB.  Basically, memory is cheaper
than flash.  When you have designs that are very cost sensitive (to put
it lightly), for example adding a 50 cent part is a major event.  You
cannot just say we need more flash...  If we are to continue to support
the embedded market for Linux,  every decision we make as too what
feature gets put in, which ones get dropped have to be made with
everyone in mind.  What is good for the desktop market, may not be the
best solution for the embedded market.  BTW: When I mean embedded I do
not mean Ipaq or Palm.  These are small computers with a completely
different set of requirements than a 1U pizza box headless storage
controller/switch/etc.



On Fri, 2006-01-20 at 22:03 +0200, P. Christeas wrote:
> On Friday 20 January 2006 9:49 pm, you wrote:
> > Actually what we have currently done is seperate the ramdisk.gz image
> > from the kernel. By default the kernel would combine the two images.
> > This was done for a number of reasons,  being able to customize the
> > ramdisk apart from the kernel (different applications),  updating the
> > ramdisk/kernel seperate from one another, flash and memory constraints.
> >
> > In our process the embedded ramdisk is the filesystem.  It contains
> > busybox, all of our applications/kernel modules, glibc, etc.  And before
> > you ask, yes we have looked at uCLibc, but it does not fit our needs,
> > especially now that it is coupled with its own ramdisk creation tools.
> >
> > One other thing that bothers me is the ability for ramfs to grow/shrink
> > as needed.  This could be a major roadblock for us.  With an embedded
> > system, I would be hesitant to put in a filesystem that could gobble up
> > all of the memory.  At least with ramdisk, you would get a not enough
> > room message, with ramfs it just keeps growing until the kernel locks-
> > up.  (At least this is my impression.)  This is a very dangerous for an
> > embedded application.
> >
> 
> If you don't mind, you could post our conversation in public (if your layout 
> is not something secret). Tell me if I should cc to linux-mips.
> 
> One point is that nowadays, systems are *not* diskless. Since flash memory can 
> be used as a partition, there should be no reason to have a kernel with 
> embedded rootfs.
> Why not have sth like squashfs or jffs2 (rw) somewhere in the memory and use 
> it (which wouldn't require any RAM)?
> If you want, you could consider a "failsafe" ramdisk/fs that would load in 
> special cases (explicit load or a button press at boottime) where you need to 
> update the squashfs on the flash.
-- 
Any content within this email is provided “AS IS” for informational purposes only.  No contract will be formed between the parties by virtue of this email. 
/***********************
Marc Karasek
System Lead Technical Engineer
iVivity Inc.
T 678-990-1550 x238
F 678-990-1551
***********************/