: Rewrite of arch/mips/ramdisk/

Attached is a patch for 2.6 that rewrites how embedded mips ramdisks are merged into the kernel. It basically replicates the method used by 2.6's initramfs (for linking in config.gz and such into the kernel, see the files in usr/ in the source tree).

The upside of this is the resulting ramdisk.o file has all the correct ELF flags, which is needed for the few o64 targets used (IP32, IP22), and it gets built to the right ABI (avoiding the binutils error about mixing 32/64bit code).

Tested on Indy R5K, O2 R5K and Cobalt RaQ2.

--Kumba

"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

diff -Naurp linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/Makefile linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/Makefile
@@ -2,19 +2,12 @@
 # Makefile for a ramdisk image
 #
 
+# Builds from ramdisk.S using .incbin
 obj-y += ramdisk.o
 
-
-O_FORMAT = $(shell $(OBJDUMP) -i | head -n 2 | grep elf32)
+# Set the path accordingly
 img := $(subst ",,$(CONFIG_EMBEDDED_RAMDISK_IMAGE))
-# add $(src) when $(img) is relative
 img := $(subst $(src)//,/,$(src)/$(img))
 
-quiet_cmd_ramdisk = LD      $@
-define cmd_ramdisk
-	$(LD) $(LDFLAGS) -T $(src)/ld.script -b binary --oformat $(O_FORMAT) -o $@ $(img)
-endef
-
-$(obj)/ramdisk.o: $(img) $(src)/ld.script
-	$(call cmd,ramdisk)
-
+# Pass the filename to ${AS}
+EXTRA_AFLAGS="-DMIPS_EMBEDDED_RAMDISK=\"$(img)\""

diff -Naurp linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/ld.script linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/ld.script
@@ -1,9 +0,0 @@
-OUTPUT_ARCH(mips)
-SECTIONS
-{
-  .initrd :
-  {
-       *(.data)
-  }
-}
-

diff -Naurp linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/ramdisk.S linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/ramdisk.S
@@ -0,0 +1,9 @@
+/*
+ * For a detailed explanation of this file and the 
+ * commands, see usr/initramfs_data.S in the root 
+ * of this source tree.
+ */
+
+.section .initrd,"a"
+.incbin MIPS_EMBEDDED_RAMDISK
+

So why do you keep it instead of using initramfs as you should - which is the portable method useable on all ports.

Not sure I'm following what you're asking/referring to. This is for an embedded filesystem initrd, like for a small busybox-based initrd, useful for netboot images and the like. From looking at the initramfs stuff in usr/, that looks to be specific for linking config.gz into the kernel, and not configurable to link in a filesystem-based initrd.

I basically mimiced the method in usr/ for arch/mips/ramdisk/. If there's some more global mechanism for utilizing this and tying in an initrd, then I didn't see it. The current code in arch/mips/ramdisk/ is virtually the same as the stuff in arch/sh/ramdisk/, so it doesn't look like any kind of code sharing is going on between the various ports that have an optional embedded ramdisk.

--Kumba

"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

Ahh, I see. Ralf pointed me at CONFIG_INITRAMFS_SOURCE in 2.6.10. My patch was based on 2.6.9, and I didn't exactly think this specific bit of the kernel would change between 2.6.9 and 2.6.10. Go figure.

It looks like this option, which afaict, doesn't seem to have an entry anywhere in Kconfig, specifies a list of files for inclusion in a cpio archive that's bundled into the kernel. My question then is, can a lookback-mountable filesystem image be included in this list, and the kernel, given /dev/ram0 as root, know to mount and use the loopback image?

--Kumba

"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

I guess you and many others don't realize the speed of the Linux evolution these days. Between 2.6.10-rc1 and 2.6.10-rc2 there's about 9MB of patches. Even if much of the code is not changing - the halftime for patches has reduced quite a bit ...

Ralf

I'm aware of the speed at which the kernel changes. What I didn't expect was that I picked the one time to try and fix mips embedded ramdisks with a more permanent fix at the same time someone else did -- just the someone else had a much better idea that applied more globally. Call it bad timing with a little bit of coincidence mixed in.

I'll have to figure out how this CONFIG_INITRAMFS_SOURCE works now (it doesn't look like the Kconfig bits are in yet, a quick grep only shows mentions in defconfigs), and then see how it can replace the older embedded ramdisk idea.

--Kumba

"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

You could include a loop-back mountable filesystem image. But that's not even nessecary. The kernel will call /init of the files in the initramfs, and you could just store everything you'd store in the loopback filesystem directly in the initramfs image.

Right. So this means CONFIG_EMBEDDED_RAMDISK and CONFIG_EMBEDDED_RAMDISK_IMAGE have become obsolete. So unless somebody delivers a convincing argument I'm going to remove these options.

Ralf