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
> 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
> however, use initramfs. I maintained patches for a time (up until ~2.6.13)
> 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,
> I'm not going to maintain those patches any longer.
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.
System Lead Technical Engineer
T 678-990-1550 x238