problems with external initramfs passed to device tree kernel

problems with external initramfs passed to device tree kernel

[John Linn]

I'm not sure this is specific to ARM, but that's what I'm on so I
thought I'd ask.  I'm also running a device tree kernel.  I've tried
it on 3.0 and 3.3 kernels.

I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the kernel
to get it to boot with an external initramfs image. It says the image
is not?good (junk in it), but it boots.  The same image boots fine
when built into the kernel using INITRAMFS_SOURCE, even with
BLK_DEV_RAM in the kernel.

I've done quite a bit of digging at the init/initramfs.c and it's not
obvious to me where the issue lies (user error probably).

Any thoughts would be appreciated.

Thanks,
John

problems with external initramfs passed to device tree kernel

[Ben Peddell]

On 13/06/2012 9:12 AM, John Linn wrote:
> I'm not sure this is specific to ARM, but that's what I'm on so I 
> thought I'd ask.  I'm also running a device tree kernel.  I've
> tried it on 3.0 and 3.3 kernels.
> 
> I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the
> kernel to get it to boot with an external initramfs image. It says
> the image is not?good (junk in it), but it boots.  The same image
> boots fine when built into the kernel using INITRAMFS_SOURCE, even
> with BLK_DEV_RAM in the kernel.
> 
> I've done quite a bit of digging at the init/initramfs.c and it's
> not obvious to me where the issue lies (user error probably).
> 
> Any thoughts would be appreciated.

If the size of the initramfs image is set in either devicetree or the
initrd= kernel parameter, and is larger than the actual initramfs
image is, then the kernel throws the image away if it's followed by
anything other than null bytes.  U-boot doesn't initialize the RAM to
zeroes, so the initramfs will be followed by whatever was in RAM -
usually 0xFF with zero bits here and there, or the decayed contents
before the previous shutdown if the machine was off for a very short time.

I will follow up with a patch that should remedy this issue.  Please
let me know if there's a better way to do this.

-- 
Ben Peddell
IT Support Bowen, Collinsville and Proserpine Catholic schools
http://klightspeed.killerwolves.net/

[PATCH] initramfs: handle trailing junk after valid image

[Ben Peddell]

The initramfs handling since commit df37bd15 has been rejecting
valid images that have garbage after them.  For example, on an
architecture where the initramfs address and size are specified
as a kernel parameter (specifically unicore32 and arm), specifying
e.g. initrd=0x01000000,4M will not work unless the image is padded
with nulls to 4MiB.  This is unlikely to occur if the user is using
this parameter to work around a bug in the bootloader.

---
 init/initramfs.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 84c6bf1..26c2cb1 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -467,6 +467,9 @@ static char * __init unpack_to_rootfs(char *buf, unsigned len)
 					 compress_name);
 				message = msg_buf;
 			}
+		} else if (state == Reset) {
+			my_inptr = len;
+			pr_warn("%s: junk at end of compressed archive\n", __func__);
 		} else
 			error("junk in compressed archive");
 		if (state != Reset)
-- 
1.7.3.4

[PATCH] initramfs: handle trailing junk after valid image

[Sergei Shtylyov]

Hello.

On 08/06/2012 01:32 PM, Ben Peddell wrote:

> The initramfs handling since commit df37bd15 has been rejecting

   Please also specify the summary of that commit in parens.

> valid images that have garbage after them.  For example, on an
> architecture where the initramfs address and size are specified
> as a kernel parameter (specifically unicore32 and arm), specifying
> e.g. initrd=0x01000000,4M will not work unless the image is padded
> with nulls to 4MiB.  This is unlikely to occur if the user is using
> this parameter to work around a bug in the bootloader.

   You didn't sign off the patchs, so it can't br applied.

WBR, Sergei

[PATCH 1/1] initramfs: handle trailing junk after valid image (try 2)

[Ben Peddell]

The initramfs handling since commit df37bd15 (initramfs: handle 
unrecognised decompressor when unpacking) has been rejecting
valid images that have garbage after them.  For example, on an
architecture where the initramfs address and size are specified
as a kernel parameter (specifically unicore32 and arm), specifying
e.g. initrd=0x01000000,4M will not work unless the image is padded
with nulls to 4MiB.  This is unlikely to occur if the user is using
this parameter to work around a bug in the bootloader.

Signed-off-by: Ben Peddell <klightspeed@killerwolves.net>

---
 init/initramfs.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 84c6bf1..26c2cb1 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -467,6 +467,9 @@ static char * __init unpack_to_rootfs(char *buf, unsigned len)
 					 compress_name);
 				message = msg_buf;
 			}
+		} else if (state == Reset) {
+			my_inptr = len;
+			pr_warn("%s: junk at end of compressed archive\n", __func__);
 		} else
 			error("junk in compressed archive");
 		if (state != Reset)
-- 
1.7.3.4