From: Ed Martini <martini@c2micro.com>
To: linux-mips@linux-mips.org
Subject: Re: initrd problem
Date: Tue, 15 Mar 2005 14:37:45 -0800 [thread overview]
Message-ID: <423763B9.2000907@c2micro.com> (raw)
In-Reply-To: <20050314110101.GF7759@linux-mips.org>
Ralf Baechle wrote:
>On Thu, Mar 10, 2005 at 03:42:04PM -0800, Ed Martini wrote:
>
>
>>Should I put CONFIG_EMBEDDED_RAMDISK and its ilk back into my kernel, or
>>write an ELF version of addinitrd? Other ideas?
>>
>>
>
>Things vanish for a reason ... Try CONFIG_INITRAMFS_SOURCE instead.
>
> Ralf
>
Ok. Then let's get rid of it completly, and provide a replacement that
works.
There were vestiges of embedded initrd in the ld script that were
confusing when trying to sort things out. That, in conjunction with
Documentation/initrd.txt made it hard to discover early user space and
initramfs when coming from the old world (2.4).
Also, unless you move the location of .init.ramfs, it gets freed twice,
leading to a panic.
From the documentation alone it's impossible to figure out how to build
your initramfs. In various places the docs refer to the initial
executable as /linuxrc, /kinit, /init, and possibly others. If you read
init/main.c you see that for an initramfs, your initial process will be
started from /init.
diff -urN linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S
linux/arch/mips/kernel/vmlinux.lds.S
--- linux-2.6.11-linux-mips.org/arch/mips/kernel/vmlinux.lds.S
2005-03-15 13:41:51.000000000 -0800
+++ linux/arch/mips/kernel/vmlinux.lds.S 2005-03-15 14:34:00.339164936 -0800
@@ -54,13 +54,6 @@
*(.data)
- /* Align the initial ramdisk image (INITRD) on page boundaries. */
- . = ALIGN(4096);
- __rd_start = .;
- *(.initrd)
- . = ALIGN(4096);
- __rd_end = .;
-
CONSTRUCTORS
}
_gp = . + 0x8000;
@@ -82,6 +75,13 @@
_edata = .; /* End of data section */
+ /* Align the initial ramfs image on page boundaries. */
+ /* It will be freed by init/initramfs.c */
+ . = ALIGN(4096);
+ __initramfs_start = .;
+ .init.ramfs : { *(.init.ramfs) }
+ __initramfs_end = .;
+
/* will be freed after init */
. = ALIGN(4096); /* Init code and data */
__init_begin = .;
@@ -118,10 +118,6 @@
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
SECURITY_INIT
- . = ALIGN(4096);
- __initramfs_start = .;
- .init.ramfs : { *(.init.ramfs) }
- __initramfs_end = .;
. = ALIGN(32);
__per_cpu_start = .;
.data.percpu : { *(.data.percpu) }
next prev parent reply other threads:[~2005-03-15 22:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-10 23:42 initrd problem Ed Martini
2005-03-11 0:41 ` Kumba
2005-03-14 11:01 ` Ralf Baechle
2005-03-15 22:37 ` Ed Martini [this message]
2005-03-16 12:06 ` Ralf Baechle
2005-03-17 0:23 ` initrd/initramfs problem Ed Martini
2005-03-25 19:24 ` Observations on LLSC and SMP Ed Martini
2005-03-25 19:37 ` Daniel Jacobowitz
2005-03-25 22:46 ` Ed Martini
2005-03-25 22:53 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2005-04-15 6:31 initrd problem colin
2005-04-15 6:31 ` colin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=423763B9.2000907@c2micro.com \
--to=martini@c2micro.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox