problems with external initramfs passed to device tree kernel

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

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/

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(-)

index 84c6bf1..26c2cb1 100644
@@ -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

Hello.

Please also specify the summary of that commit in parens.

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

WBR, Sergei

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.

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

index 84c6bf1..26c2cb1 100644
@@ -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