[PATCH]: Rewrite of arch/mips/ramdisk/

[PATCH]: Rewrite of arch/mips/ramdisk/

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

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

[-- Attachment #2: mips-new-way-of-doing-ramdisks.patch --]
[-- Type: text/plain, Size: 1865 bytes --]

diff -Naurp linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/Makefile linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/Makefile
--- linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/Makefile	2004-06-08 16:41:55.000000000 -0400
+++ linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/Makefile	2004-11-13 17:16:59.124686128 -0500
@@ -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
--- linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/ld.script	2001-11-13 00:35:54.000000000 -0500
+++ linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/ld.script	1969-12-31 19:00:00.000000000 -0500
@@ -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
--- linux-2.6.10-rc1.mips.orig/arch/mips/ramdisk/ramdisk.S	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.10-rc1.mips.mod/arch/mips/ramdisk/ramdisk.S	2004-11-13 17:17:59.825458208 -0500
@@ -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
+

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Christoph Hellwig]

On Sun, Nov 14, 2004 at 01:43:08AM -0500, Kumba wrote:
> 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).

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

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Kumba]

Christoph Hellwig wrote:
> 
> 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

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Kumba]

Kumba wrote:
> 
> 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.

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

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Ralf Baechle]

On Sun, Nov 14, 2004 at 02:31:18PM -0500, Kumba wrote:

> 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?

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

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Kumba]

Ralf Baechle wrote:
> 
> 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 ...

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

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Christoph Hellwig]

> 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?

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.

Re: [PATCH]: Rewrite of arch/mips/ramdisk/

[Ralf Baechle]

On Mon, Nov 15, 2004 at 07:05:07PM +0100, Christoph Hellwig wrote:

> 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