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