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

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

[zhuzhenhua]

I download the kernel from linux-mips, and select to embedded
ramdisk.gz into vmlinux.
but  i can't find where to place the ramdisk.gz.
I try to put ramdisk.gz  under top dir, or arch/mips/boot/, but it
does not work.
 can someone give any hints?


Best regards

zhuzhenhua

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

[Marc Karasek]

Look under arch/mips/ramdisk (I think).  This is where you should put the ramdisk.gz image and the compiler will pick it up and put it into the vmlinux image for you.  

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.
PH: 678-990-1550 x238
Fax: 678-990-1551
<**************************>



-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org]On Behalf Of zhuzhenhua
Sent: Saturday, January 14, 2006 11:22 PM
To: linux-mips
Subject: how to emdedded ramdisk.gz in vmlinux for linux-2.6.14?


I download the kernel from linux-mips, and select to embedded
ramdisk.gz into vmlinux.
but  i can't find where to place the ramdisk.gz.
I try to put ramdisk.gz  under top dir, or arch/mips/boot/, but it
does not work.
 can someone give any hints?


Best regards

zhuzhenhua

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

[Kumba]

Marc Karasek wrote:
> Look under arch/mips/ramdisk (I think).  This is where you should put the ramdisk.gz image and the compiler will pick it up and put it into the vmlinux image for you.  

Embedded Ramdisk support in 2.6 is deprecated and removed from the tree for 
kernels >=2.6.10.  You need to use initramfs now to get an embedded userland to 
work.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

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

[Marc Karasek]

Is this a better solution than having the ramdisk embedded? 

It seems that most of the MIPS development is embedded designs and this
could be a problem if it is not :

1) Easier 
or
2) Faster



On Mon, 2006-01-16 at 19:26 -0500, Kumba wrote:
> Marc Karasek wrote:
> > Look under arch/mips/ramdisk (I think).  This is where you should put the ramdisk.gz image and the compiler will pick it up and put it into the vmlinux image for you.  
> 
> Embedded Ramdisk support in 2.6 is deprecated and removed from the tree for 
> kernels >=2.6.10.  You need to use initramfs now to get an embedded userland to 
> work.
> 
> 
> --Kumba
> 
-- 
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
***********************/

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

[Kumba]

Marc Karasek wrote:
> Is this a better solution than having the ramdisk embedded? 

This is embedding the ramdisk.  Only in a different way.


> It seems that most of the MIPS development is embedded designs and this
> could be a problem if it is not :
> 
> 1) Easier 

Not exactly easier, initially.  I spent near a few weeks figuring initramfs out. 
  The kernel is rather picky on certain things.  The main point is you need 
/init, and if it's a script, then the very first line must be a hashbang 
(!#/bin/blah).  Those two gave me headaches for awhile.  Other oddities can 
occur that make initramfs a bit of a pain initially.


> or
> 2) Faster

Faster by what?  initramfs is unique because it resides on a level above the 
arches, so it tends to be a sort of universal ramdisk.  SGI Origin system 
couldn't use ramdisks originally because of their memory structure.  They can, 
however, use initramfs.  I maintained patches for a time (up until ~2.6.13) that 
added embedded ramdisk support back into the kernel, but now that I have 
initramfs down pretty well (a tool does the grunt work for my needs, actually), 
I'm not going to maintain those patches any longer.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

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

[Marc Karasek]

Is the process still the same.  In that you create a ramdisk image that
can be mounted, just using initramfs instead?   

We will be moving to 2.6.x for our next chip and currently have scripts
to create a ramdisk with busybox embedded.  If these cannot be used
anymore, I may want to take over the patches for ramdisk from you and
maintain them.  Otherwise our sdk would have to change and the tools,
etc. and that is not a desireable option......

IMO: Fixing something that was not broken is not a very good idea. :-)

On Tue, 2006-01-17 at 20:10 -0500, Kumba wrote:
> Marc Karasek wrote:
> > Is this a better solution than having the ramdisk embedded? 
> 
> This is embedding the ramdisk.  Only in a different way.
> 
> 
> > It seems that most of the MIPS development is embedded designs and this
> > could be a problem if it is not :
> > 
> > 1) Easier 
> 
> Not exactly easier, initially.  I spent near a few weeks figuring initramfs out. 
>   The kernel is rather picky on certain things.  The main point is you need 
> /init, and if it's a script, then the very first line must be a hashbang 
> (!#/bin/blah).  Those two gave me headaches for awhile.  Other oddities can 
> occur that make initramfs a bit of a pain initially.
> 
> 
> > or
> > 2) Faster
> 
> Faster by what?  initramfs is unique because it resides on a level above the 
> arches, so it tends to be a sort of universal ramdisk.  SGI Origin system 
> couldn't use ramdisks originally because of their memory structure.  They can, 
> however, use initramfs.  I maintained patches for a time (up until ~2.6.13) that 
> added embedded ramdisk support back into the kernel, but now that I have 
> initramfs down pretty well (a tool does the grunt work for my needs, actually), 
> I'm not going to maintain those patches any longer.
> 
> 
> --Kumba
> 
-- 
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
***********************/

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

[Stuart Longland]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

Marc Karasek **top-posted**: (Reading emails bottom-to-top is no fun)
> Is the process still the same.  In that you create a ramdisk image that
> can be mounted, just using initramfs instead?   
> 
> We will be moving to 2.6.x for our next chip and currently have scripts
> to create a ramdisk with busybox embedded.  If these cannot be used
> anymore, I may want to take over the patches for ramdisk from you and
> maintain them.  Otherwise our sdk would have to change and the tools,
> etc. and that is not a desireable option......

Initramfs works by generating a cpio archive of a directory, and
embedding a compressed version of that.  This is unpacked at boot time,
into something similar to a tmpfs-like filesystem.  It then starts /init
to bring the system online (identical to /linuxrc).

There's a couple of things you can do.  One, is to simply adapt your
scripts to create a cpio archive directly, and then set INITRAMFS_SOURCE
to the full path to your cpio archive.

Alternatively, the kernel can create the cpio archive for you, simply
point INITRAMFS_SOURCE at the root directory.  You can also use this
trick to import a initrd image into initramfs ... simply loop-mount the
initrd somewhere, then point INITRAMFS_SOURCE at the mountpoint.  (Ohh,
and don't forget to `ln -s /linuxrc /init` in your image)

So yeah, there'll be modifications required ... but the changes should
be minimal.  I'm guessing it'll possibly even simplify the tools -- as
you don't have to worry about `dd`ing a ramdisk image from /dev/zero,
running losetup, then formatting, mounting and transferring the filesystem.
-- 
Stuart Longland (aka Redhatter)              .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[Kumba]

Marc Karasek wrote:
> Is the process still the same.  In that you create a ramdisk image that
> can be mounted, just using initramfs instead?   

It's actually simpler than that, insofar as creating the archive.  There are two 
ways that I've tried, probably another exists as well.  None involve the mess of 
creating a mountable image.

1) In the scripts/ dir in the kernel tree, there's a script, 
gen_initramfs_list.sh.  chmod +x it, and pass to it (as its only argument) an 
absolute path pointing to a ready-to-go root file system that will be loaded by 
the machine that boots the subsequently produced kernel.  The output of 
gen_initramfs_list should be directed to a text file -- it's a text listing of 
every file in the directory passed, including mode params, symlink destination, 
whether it's a device or not (and if is, how to re-create it), etc..  This text 
file can then be passed to the initramfs option in menuconfig, and the kernel 
pulls in the files and rolls them into its initramfs cpio archive it builds.

2) cpio up a ready-to-go root file system and pass that to the same initramfs 
option in menuconfig.


Provided the root filesystem is setup properly, just don't pass root= on the 
command line, and the kernel takes over loading and running the main startup 
script (it's either /init or /linuxrc that it looks for, one of the two).


> We will be moving to 2.6.x for our next chip and currently have scripts
> to create a ramdisk with busybox embedded.  If these cannot be used
> anymore, I may want to take over the patches for ramdisk from you and
> maintain them.  Otherwise our sdk would have to change and the tools,
> etc. and that is not a desireable option......

This isn't that big of a change actually.  As described above, it's decidedly 
simpler, as you don't have to rely on any file system (it's basically the same 
as the old MS-DOS ramdisks some utilities diskettes would load up and dump tools 
into)


> IMO: Fixing something that was not broken is not a very good idea. :-)

I thought the same initially, but in truth, initramfs is far simpler, once you 
figure it out.  I even fixed the embedded ramdisk to handle linking in objects 
files with conflicting ABIs (encountered when we built netboot images for SGI O2 
because at the time, we built O2's kernels with -mabi=o64 which uses some mean 
tricks to stuff 64bit code into a 32bit file; ld hated that).  Of course, I did 
this fix about an hour after Ralf removed the ramdisk code from 2.6.10 CVS. 
Talk about a sense of timing.

Especially once we found out initramfs loaded flawlessly on Origin, it was 
essentially deemed to become the replacement.



--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

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

[Marc Karasek]

I am going to have to take a good look at this before making any
changes.  There are other things we must consider.  I may still want to
grab your patches,  if in the end we see this as adding to much
overhead.  

Two things I will have to look at very closely is the size of the
ramdisk.gz vs this cpio archive (how much bigger is one over the other?)
and how cleanly can we seperate the cpio archive from the kernel to have
two images instead of one big one.  If either of these items fails
muster, then we cannot use the initramfs and must go back to ramdisk.gz.
  

On Thu, 2006-01-19 at 23:11 -0500, Kumba wrote:
> Marc Karasek wrote:
> > Is the process still the same.  In that you create a ramdisk image that
> > can be mounted, just using initramfs instead?   
> 
> It's actually simpler than that, insofar as creating the archive.  There are two 
> ways that I've tried, probably another exists as well.  None involve the mess of 
> creating a mountable image.
> 
> 1) In the scripts/ dir in the kernel tree, there's a script, 
> gen_initramfs_list.sh.  chmod +x it, and pass to it (as its only argument) an 
> absolute path pointing to a ready-to-go root file system that will be loaded by 
> the machine that boots the subsequently produced kernel.  The output of 
> gen_initramfs_list should be directed to a text file -- it's a text listing of 
> every file in the directory passed, including mode params, symlink destination, 
> whether it's a device or not (and if is, how to re-create it), etc..  This text 
> file can then be passed to the initramfs option in menuconfig, and the kernel 
> pulls in the files and rolls them into its initramfs cpio archive it builds.
> 
> 2) cpio up a ready-to-go root file system and pass that to the same initramfs 
> option in menuconfig.
> 
> 
> Provided the root filesystem is setup properly, just don't pass root= on the 
> command line, and the kernel takes over loading and running the main startup 
> script (it's either /init or /linuxrc that it looks for, one of the two).
> 
> 
> > We will be moving to 2.6.x for our next chip and currently have scripts
> > to create a ramdisk with busybox embedded.  If these cannot be used
> > anymore, I may want to take over the patches for ramdisk from you and
> > maintain them.  Otherwise our sdk would have to change and the tools,
> > etc. and that is not a desireable option......
> 
> This isn't that big of a change actually.  As described above, it's decidedly 
> simpler, as you don't have to rely on any file system (it's basically the same 
> as the old MS-DOS ramdisks some utilities diskettes would load up and dump tools 
> into)
> 
> 
> > IMO: Fixing something that was not broken is not a very good idea. :-)
> 
> I thought the same initially, but in truth, initramfs is far simpler, once you 
> figure it out.  I even fixed the embedded ramdisk to handle linking in objects 
> files with conflicting ABIs (encountered when we built netboot images for SGI O2 
> because at the time, we built O2's kernels with -mabi=o64 which uses some mean 
> tricks to stuff 64bit code into a 32bit file; ld hated that).  Of course, I did 
> this fix about an hour after Ralf removed the ramdisk code from 2.6.10 CVS. 
> Talk about a sense of timing.
> 
> Especially once we found out initramfs loaded flawlessly on Origin, it was 
> essentially deemed to become the replacement.
> 
> 
> 
> --Kumba
> 
-- 
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
***********************/

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

[Marc Karasek]

I am not entirely sold on this initramfs.  

I have a question:

>From what I have read so far, it seems that this is meant as a stepping
stone to booting/mounting the real system.  Has anyone used this where
the initramfs is the filesystem and the endpoint in the boot process?  


On Thu, 2006-01-19 at 23:11 -0500, Kumba wrote:
> Marc Karasek wrote:
> > Is the process still the same.  In that you create a ramdisk image that
> > can be mounted, just using initramfs instead?   
> 
> It's actually simpler than that, insofar as creating the archive.  There are two 
> ways that I've tried, probably another exists as well.  None involve the mess of 
> creating a mountable image.
> 
> 1) In the scripts/ dir in the kernel tree, there's a script, 
> gen_initramfs_list.sh.  chmod +x it, and pass to it (as its only argument) an 
> absolute path pointing to a ready-to-go root file system that will be loaded by 
> the machine that boots the subsequently produced kernel.  The output of 
> gen_initramfs_list should be directed to a text file -- it's a text listing of 
> every file in the directory passed, including mode params, symlink destination, 
> whether it's a device or not (and if is, how to re-create it), etc..  This text 
> file can then be passed to the initramfs option in menuconfig, and the kernel 
> pulls in the files and rolls them into its initramfs cpio archive it builds.
> 
> 2) cpio up a ready-to-go root file system and pass that to the same initramfs 
> option in menuconfig.
> 
> 
> Provided the root filesystem is setup properly, just don't pass root= on the 
> command line, and the kernel takes over loading and running the main startup 
> script (it's either /init or /linuxrc that it looks for, one of the two).
> 
> 
> > We will be moving to 2.6.x for our next chip and currently have scripts
> > to create a ramdisk with busybox embedded.  If these cannot be used
> > anymore, I may want to take over the patches for ramdisk from you and
> > maintain them.  Otherwise our sdk would have to change and the tools,
> > etc. and that is not a desireable option......
> 
> This isn't that big of a change actually.  As described above, it's decidedly 
> simpler, as you don't have to rely on any file system (it's basically the same 
> as the old MS-DOS ramdisks some utilities diskettes would load up and dump tools 
> into)
> 
> 
> > IMO: Fixing something that was not broken is not a very good idea. :-)
> 
> I thought the same initially, but in truth, initramfs is far simpler, once you 
> figure it out.  I even fixed the embedded ramdisk to handle linking in objects 
> files with conflicting ABIs (encountered when we built netboot images for SGI O2 
> because at the time, we built O2's kernels with -mabi=o64 which uses some mean 
> tricks to stuff 64bit code into a 32bit file; ld hated that).  Of course, I did 
> this fix about an hour after Ralf removed the ramdisk code from 2.6.10 CVS. 
> Talk about a sense of timing.
> 
> Especially once we found out initramfs loaded flawlessly on Origin, it was 
> essentially deemed to become the replacement.
> 
> 
> 
> --Kumba
> 
-- 
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
***********************/

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

[Marc Karasek]

I am not entirely sold on this initramfs.  

I have a question:

From what I have read so far, it seems that this is meant as a stepping
stone to booting/mounting the real system.  Has anyone used this where
the initramfs is the filesystem and the endpoint in the boot process?  


On Thu, 2006-01-19 at 23:11 -0500, Kumba wrote:
> Marc Karasek wrote:
> > Is the process still the same.  In that you create a ramdisk image that
> > can be mounted, just using initramfs instead?   
> 
> It's actually simpler than that, insofar as creating the archive.  There are two 
> ways that I've tried, probably another exists as well.  None involve the mess of 
> creating a mountable image.
> 
> 1) In the scripts/ dir in the kernel tree, there's a script, 
> gen_initramfs_list.sh.  chmod +x it, and pass to it (as its only argument) an 
> absolute path pointing to a ready-to-go root file system that will be loaded by 
> the machine that boots the subsequently produced kernel.  The output of 
> gen_initramfs_list should be directed to a text file -- it's a text listing of 
> every file in the directory passed, including mode params, symlink destination, 
> whether it's a device or not (and if is, how to re-create it), etc..  This text 
> file can then be passed to the initramfs option in menuconfig, and the kernel 
> pulls in the files and rolls them into its initramfs cpio archive it builds.
> 
> 2) cpio up a ready-to-go root file system and pass that to the same initramfs 
> option in menuconfig.
> 
> 
> Provided the root filesystem is setup properly, just don't pass root= on the 
> command line, and the kernel takes over loading and running the main startup 
> script (it's either /init or /linuxrc that it looks for, one of the two).
> 
> 
> > We will be moving to 2.6.x for our next chip and currently have scripts
> > to create a ramdisk with busybox embedded.  If these cannot be used
> > anymore, I may want to take over the patches for ramdisk from you and
> > maintain them.  Otherwise our sdk would have to change and the tools,
> > etc. and that is not a desireable option......
> 
> This isn't that big of a change actually.  As described above, it's decidedly 
> simpler, as you don't have to rely on any file system (it's basically the same 
> as the old MS-DOS ramdisks some utilities diskettes would load up and dump tools 
> into)
> 
> 
> > IMO: Fixing something that was not broken is not a very good idea. :-)
> 
> I thought the same initially, but in truth, initramfs is far simpler, once you 
> figure it out.  I even fixed the embedded ramdisk to handle linking in objects 
> files with conflicting ABIs (encountered when we built netboot images for SGI O2 
> because at the time, we built O2's kernels with -mabi=o64 which uses some mean 
> tricks to stuff 64bit code into a 32bit file; ld hated that).  Of course, I did 
> this fix about an hour after Ralf removed the ramdisk code from 2.6.10 CVS. 
> Talk about a sense of timing.
> 
> Especially once we found out initramfs loaded flawlessly on Origin, it was 
> essentially deemed to become the replacement.
> 
> 
> 
> --Kumba
> 
-- 
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
***********************/

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

[Stephen P. Becker]

Marc Karasek wrote:
> I am not entirely sold on this initramfs.  
> 
> I have a question:
> 
>>From what I have read so far, it seems that this is meant as a stepping
> stone to booting/mounting the real system.  Has anyone used this where
> the initramfs is the filesystem and the endpoint in the boot process?  

Sure.  Our Gentoo netboot installer images do this.

-Steve

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

[Marc Karasek]

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
***********************/

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

[P. Christeas]

On Friday 20 January 2006 10:47 pm, you wrote:
> 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.
>

Our discussion is quite general, I don't mean to interfere with your hardware 
design anyway. My point was just that the filesystem you mention would be 
stored in some kind of ROM anyway (either inside the kernel ELF or outside 
it). So, you wouldn't need to copy it to your RAM. That's the main feature of 
squashfs/cromfs. You can still have tmpfs for some kind of read/write 
storage.
One drawback, however, would be that the access to the ROM (in the form of 
mtd) could cost you some extra code that need to go into the kernel.

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

[Wolfgang Denk]

In message <1137790053.22994.58.camel@localhost.localdomain> you wrote:
> 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

If you have enough flash to store a compressed ramdisk image, you can
store a compressed flash file system as well. For example, you  could
use  a  cramfs file system. In most cases the ramdisk solution is the
worst option to chose. See for example
http://www.denx.de/wiki/view/DULG/RootFileSystemSelection


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer

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

[Marc Karasek]

I took a look at the page...

The one criteria, being able to update in a live system, trumps all of the other considerations.  If you cannot update a live system, then you might as well take your ball & bat and go home.  :-)

Seriously, that is a what I would call a no-brainer decision.    

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.
PH: 678-990-1550 x238
Fax: 678-990-1551
<**************************>



-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, January 20, 2006 4:04 PM
To: Marc Karasek
Cc: P. Christeas; Linux-Mips
Subject: Re: how to emdedded ramdisk.gz in vmlinux for linux-2.6.14? 


In message <1137790053.22994.58.camel@localhost.localdomain> you wrote:
> 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

If you have enough flash to store a compressed ramdisk image, you can
store a compressed flash file system as well. For example, you  could
use  a  cramfs file system. In most cases the ramdisk solution is the
worst option to chose. See for example
http://www.denx.de/wiki/view/DULG/RootFileSystemSelection


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer

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

[Marc Karasek]

I took a look at the page...

The one criteria, being able to update in a live system, trumps all of the other considerations.  If you cannot update a live system, then you might as well take your ball & bat and go home.  :-)

Seriously, that is a what I would call a no-brainer decision.    

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.
PH: 678-990-1550 x238
Fax: 678-990-1551
<**************************>



-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, January 20, 2006 4:04 PM
To: Marc Karasek
Cc: P. Christeas; Linux-Mips
Subject: Re: how to emdedded ramdisk.gz in vmlinux for linux-2.6.14? 


In message <1137790053.22994.58.camel@localhost.localdomain> you wrote:
> 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

If you have enough flash to store a compressed ramdisk image, you can
store a compressed flash file system as well. For example, you  could
use  a  cramfs file system. In most cases the ramdisk solution is the
worst option to chose. See for example
http://www.denx.de/wiki/view/DULG/RootFileSystemSelection


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer