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