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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux