SH7751R - STRANGE initramfs/rootfs behavior

SH7751R - STRANGE initramfs/rootfs behavior

[Alon Bar-Lev]

Hello,

I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
embedded initramfs, anyone have this configuration working?

I use zImage converted to srec using objcopy, load the srec into
memory and jump to the load address of the kernel.

The kernel boots, but when trying to decompress the initramfs image it
 fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.

Has anyone got this error? The initramfs image is correct. I also
dumped the memory of __initramfs_start->__initramfs_start and verified
that it matches the initramfs image on usr/initramfs_data.cpio.gz.

I then noticed that the kernel code at
init/initramfs::unpack_to_rootfs:459 supports handling  uncompressed
archives. So I compiled a kernel with uncompressed archived.

I also hooked the init/initramfs::do_name:585 functions, and see that
"/init' is passed to sys_open, and sys_open returns with -EOENT (-2).

 How can it be? shouldn't rootfs always be available?

 The same attempt on i586, mipsel is working as expected.

 Any ideas?
 1. Why decompression working for kernel and not for initramfs (crc error).
 2. Why files cannot be created on rootfs?

 Thank you,
Alon Bar-Lev.

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Alon Bar-Lev]

Forgot to mention that I tried the latest linux-sh git and it behaves the same.

Appreciate any idea regarding this,
Alon.

On 4/7/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> Hello,
>
>  I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
>  embedded initramfs, anyone have this configuration working?
>
>  I use zImage converted to srec using objcopy, load the srec into
>  memory and jump to the load address of the kernel.
>
>  The kernel boots, but when trying to decompress the initramfs image it
>   fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
>
>  Has anyone got this error? The initramfs image is correct. I also
>  dumped the memory of __initramfs_start->__initramfs_start and verified
>  that it matches the initramfs image on usr/initramfs_data.cpio.gz.
>
>  I then noticed that the kernel code at
>  init/initramfs::unpack_to_rootfs:459 supports handling  uncompressed
>  archives. So I compiled a kernel with uncompressed archived.
>
>  I also hooked the init/initramfs::do_name:585 functions, and see that
>  "/init' is passed to sys_open, and sys_open returns with -EOENT (-2).
>
>   How can it be? shouldn't rootfs always be available?
>
>   The same attempt on i586, mipsel is working as expected.
>
>   Any ideas?
>   1. Why decompression working for kernel and not for initramfs (crc error).
>   2. Why files cannot be created on rootfs?
>
>   Thank you,
>
> Alon Bar-Lev.
>

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Paul Mundt]

On Mon, Apr 07, 2008 at 04:16:01PM +0300, Alon Bar-Lev wrote:
> I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
> embedded initramfs, anyone have this configuration working?
> 
> I use zImage converted to srec using objcopy, load the srec into
> memory and jump to the load address of the kernel.
> 
> The kernel boots, but when trying to decompress the initramfs image it
>  fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
> 
> Has anyone got this error? The initramfs image is correct. I also
> dumped the memory of __initramfs_start->__initramfs_start and verified
> that it matches the initramfs image on usr/initramfs_data.cpio.gz.
> 
I've noticed this on an SH7203 (SH-2A FPU) board, which is also
big-endian. It seems to be an endianness issue, in that it's never show
up on any of the little endian configurations. If your board is
endianness selectable, I'd suggest trying little endian and seeing if
that works.

Little endian certainly gets the bulk of the testing, so it's quite
possible that there are some things broken on big endian.

Re: SH7751R - STRANGE initramfs/rootfs behavior

[David McCullough]

Jivin Paul Mundt lays it down ...
> On Mon, Apr 07, 2008 at 04:16:01PM +0300, Alon Bar-Lev wrote:
> > I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
> > embedded initramfs, anyone have this configuration working?
> > 
> > I use zImage converted to srec using objcopy, load the srec into
> > memory and jump to the load address of the kernel.
> > 
> > The kernel boots, but when trying to decompress the initramfs image it
> >  fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
> > 
> > Has anyone got this error? The initramfs image is correct. I also
> > dumped the memory of __initramfs_start->__initramfs_start and verified
> > that it matches the initramfs image on usr/initramfs_data.cpio.gz.
> > 
> I've noticed this on an SH7203 (SH-2A FPU) board, which is also
> big-endian. It seems to be an endianness issue, in that it's never show
> up on any of the little endian configurations. If your board is
> endianness selectable, I'd suggest trying little endian and seeing if
> that works.
> 
> Little endian certainly gets the bulk of the testing, so it's quite
> possible that there are some things broken on big endian.

I have done this on several big-endian mips boards,  so I don't think
it's endianess.

Most of the problems I have seen in this area were generally due to
either setting up the initramfs incorrectly,  bad dram settings or
something to do with memory maps/bootloaders and image sizes.  Not much
help I know.

Settings:

	CONFIG_BLK_DEV_INITRD=y
	CONFIG_INITRAMFS_SOURCE="/tmp/XX.ramfs.cpio"
	CONFIG_INITRAMFS_ROOT_UID=0
	CONFIG_INITRAMFS_ROOT_GID=0

and the initramfs is created with:

	cd rootfsdir; find . | cpio --quiet -o -H newc > /tmp/XX.ramfs.cpio

followed of course by a:

	make vmlinux

or whatever you need, maybe there is something in there that helps,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough@securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Paul Mundt]

On Tue, Apr 08, 2008 at 01:20:12PM +1000, David McCullough wrote:
> 
> Jivin Paul Mundt lays it down ...
> > On Mon, Apr 07, 2008 at 04:16:01PM +0300, Alon Bar-Lev wrote:
> > > I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
> > > embedded initramfs, anyone have this configuration working?
> > > 
> > > I use zImage converted to srec using objcopy, load the srec into
> > > memory and jump to the load address of the kernel.
> > > 
> > > The kernel boots, but when trying to decompress the initramfs image it
> > >  fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
> > > 
> > > Has anyone got this error? The initramfs image is correct. I also
> > > dumped the memory of __initramfs_start->__initramfs_start and verified
> > > that it matches the initramfs image on usr/initramfs_data.cpio.gz.
> > > 
> > I've noticed this on an SH7203 (SH-2A FPU) board, which is also
> > big-endian. It seems to be an endianness issue, in that it's never show
> > up on any of the little endian configurations. If your board is
> > endianness selectable, I'd suggest trying little endian and seeing if
> > that works.
> > 
> > Little endian certainly gets the bulk of the testing, so it's quite
> > possible that there are some things broken on big endian.
> 
> I have done this on several big-endian mips boards,  so I don't think
> it's endianess.
> 
Indeed, I meant more in terms of big-endian on SH. It wouldn't surprise
me if there was a path where the swabbing or something else is broken.
Especially on SH-4, I don't know anyone that has tested it recently.

I've noticed the CRC errors on the SH-2A regardless of what we have in
the cpio, but did not have time to investigate it further at the time.

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Alon Bar-Lev]

On 4/8/08, David McCullough <David_Mccullough@securecomputing.com> wrote:
>  and the initramfs is created with:
>
>         cd rootfsdir; find . | cpio --quiet -o -H newc > /tmp/XX.ramfs.cpio
>
>  followed of course by a:
>
>         make vmlinux
>
>  or whatever you need, maybe there is something in there that helps,

Thank you David!
The initramfs is OK.
I use the same process in mipsel and i368.
When I hack the kernel and make it link uncompressed initramfs, I can
see the cpio extraction. But then I see that sys_open of file creation
on rootfs returns -ENOENT.

Alon.

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Alon Bar-Lev]

On 4/8/08, Paul Mundt <lethal@linux-sh.org> wrote:
> Indeed, I meant more in terms of big-endian on SH. It wouldn't surprise
>  me if there was a path where the swabbing or something else is broken.
>  Especially on SH-4, I don't know anyone that has tested it recently.
>
>  I've noticed the CRC errors on the SH-2A regardless of what we have in
>  the cpio, but did not have time to investigate it further at the time.
>

Thank you for replying!
I cannot set the board to little endian as I try to migrate existing working
board configuration with 2.4 kernel to 2.6.
Can you please help me understand where should I look for issues?
Please note that if I skip decompression part, I have issues with creating
files on rootfs, this seems unrelated, so the problem is somewhere else.

Thanks!
Alon.

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Alon Bar-Lev]

Hello,

Any tip how I can debug this further?
Where can endianess affect memory access...

Thanks!

On 4/8/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> On 4/8/08, Paul Mundt <lethal@linux-sh.org> wrote:
>  > Indeed, I meant more in terms of big-endian on SH. It wouldn't surprise
>  >  me if there was a path where the swabbing or something else is broken.
>  >  Especially on SH-4, I don't know anyone that has tested it recently.
>  >
>  >  I've noticed the CRC errors on the SH-2A regardless of what we have in
>  >  the cpio, but did not have time to investigate it further at the time.
>  >
>
>
> Thank you for replying!
>  I cannot set the board to little endian as I try to migrate existing working
>  board configuration with 2.4 kernel to 2.6.
>  Can you please help me understand where should I look for issues?
>  Please note that if I skip decompression part, I have issues with creating
>  files on rootfs, this seems unrelated, so the problem is somewhere else.
>
>  Thanks!
>
> Alon.
>

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Paul Mundt]

On Mon, Apr 07, 2008 at 04:16:01PM +0300, Alon Bar-Lev wrote:
> Hello,
> 
> I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
> embedded initramfs, anyone have this configuration working?
> 
> I use zImage converted to srec using objcopy, load the srec into
> memory and jump to the load address of the kernel.
> 
> The kernel boots, but when trying to decompress the initramfs image it
>  fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
> 
> Has anyone got this error? The initramfs image is correct. I also
> dumped the memory of __initramfs_start->__initramfs_start and verified
> that it matches the initramfs image on usr/initramfs_data.cpio.gz.
> 
> I then noticed that the kernel code at
> init/initramfs::unpack_to_rootfs:459 supports handling  uncompressed
> archives. So I compiled a kernel with uncompressed archived.
> 
> I also hooked the init/initramfs::do_name:585 functions, and see that
> "/init' is passed to sys_open, and sys_open returns with -EOENT (-2).
> 
>  How can it be? shouldn't rootfs always be available?
> 
>  The same attempt on i586, mipsel is working as expected.
> 
>  Any ideas?
>  1. Why decompression working for kernel and not for initramfs (crc error).
>  2. Why files cannot be created on rootfs?
> 
Ok, this was fun to debug. The problem was related to initrd handling,
not the initramfs bits itself. init/initramfs.c:populate_rootfs() itself
has no problems on the __initramfs_start -> __initramfs_end unpack, but
after this, initrd_start is tested unconditionally and triggers an
additional call in to unpack_to_rootfs().

Inserting a dump_mem() in unpack_to_rootfs() after the inbuf pointer has
been assigned (prior to the gunzip()), you can see that there are
multiple invocations, and while the first is correct, the second one is
complete garbage -- which is ultimately what causes it to bail out with a
vague crc or header magic mismatch error.

The reason for this is that the default values in .empty_zero_page
contain an initrd start/size and valid loader type, and while some boot
loader and kernel configurations fix this up correctly, others do not,
which cause the defaults to be used instead.

This should fix it up, and also provide some more debugging information
so it's more obvious how the boot params in .empty_zero_page look on
entry.

---

diff --git a/arch/sh/kernel/head_32.S b/arch/sh/kernel/head_32.S
index d67d7ed..ae0a382 100644
--- a/arch/sh/kernel/head_32.S
+++ b/arch/sh/kernel/head_32.S
@@ -30,8 +30,8 @@ ENTRY(empty_zero_page)
 	.long	0		/* RAMDISK_FLAGS */
 	.long	0x0200		/* ORIG_ROOT_DEV */
 	.long	1		/* LOADER_TYPE */
-	.long	0x00360000	/* INITRD_START */
-	.long	0x000a0000	/* INITRD_SIZE */
+	.long	0x00000000	/* INITRD_START */
+	.long	0x00000000	/* INITRD_SIZE */
 #ifdef CONFIG_32BIT
 	.long	0x53453f00 + 32	/* "SE?" = 32 bit */
 #else
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 516bde9..bca2bbc 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -292,6 +292,17 @@ void __init setup_arch(char **cmdline_p)
 
 	ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
 
+	printk(KERN_NOTICE "Boot params:\n"
+			   "... MOUNT_ROOT_RDONLY - %08lx\n"
+			   "... RAMDISK_FLAGS     - %08lx\n"
+			   "... ORIG_ROOT_DEV     - %08lx\n"
+			   "... LOADER_TYPE       - %08lx\n"
+			   "... INITRD_START      - %08lx\n"
+			   "... INITRD_SIZE       - %08lx\n",
+			   MOUNT_ROOT_RDONLY, RAMDISK_FLAGS,
+			   ORIG_ROOT_DEV, LOADER_TYPE,
+			   INITRD_START, INITRD_SIZE);
+
 #ifdef CONFIG_BLK_DEV_RAM
 	rd_image_start = RAMDISK_FLAGS & RAMDISK_IMAGE_START_MASK;
 	rd_prompt = ((RAMDISK_FLAGS & RAMDISK_PROMPT_FLAG) != 0);

Re: SH7751R - STRANGE initramfs/rootfs behavior

[Roni Feldman]

It seems that the bug in memcpy caused the specific crc error in my
setup. Replacing
memcpy-sh4.S with the more generic sh memcpy.S seemed to fix the issue
in inflate()'s code.
Later on I will apply Hideo's patch to see if the problem returns.
Looks like one bug caused another to be found, which is always good news.

On Tue, May 13, 2008 at 10:38 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Apr 07, 2008 at 04:16:01PM +0300, Alon Bar-Lev wrote:
>> Hello,
>>
>> I am trying to boot 2.6.24 kernel on SH7751R big endian (sh4eb) using
>> embedded initramfs, anyone have this configuration working?
>>
>> I use zImage converted to srec using objcopy, load the srec into
>> memory and jump to the load address of the kernel.
>>
>> The kernel boots, but when trying to decompress the initramfs image it
>>  fails with "crc error",  resulting from lib/inflate.c::gunzip:1250.
>>
>> Has anyone got this error? The initramfs image is correct. I also
>> dumped the memory of __initramfs_start->__initramfs_start and verified
>> that it matches the initramfs image on usr/initramfs_data.cpio.gz.
>>
>> I then noticed that the kernel code at
>> init/initramfs::unpack_to_rootfs:459 supports handling  uncompressed
>> archives. So I compiled a kernel with uncompressed archived.
>>
>> I also hooked the init/initramfs::do_name:585 functions, and see that
>> "/init' is passed to sys_open, and sys_open returns with -EOENT (-2).
>>
>>  How can it be? shouldn't rootfs always be available?
>>
>>  The same attempt on i586, mipsel is working as expected.
>>
>>  Any ideas?
>>  1. Why decompression working for kernel and not for initramfs (crc error).
>>  2. Why files cannot be created on rootfs?
>>
> Ok, this was fun to debug. The problem was related to initrd handling,
> not the initramfs bits itself. init/initramfs.c:populate_rootfs() itself
> has no problems on the __initramfs_start -> __initramfs_end unpack, but
> after this, initrd_start is tested unconditionally and triggers an
> additional call in to unpack_to_rootfs().
>
> Inserting a dump_mem() in unpack_to_rootfs() after the inbuf pointer has
> been assigned (prior to the gunzip()), you can see that there are
> multiple invocations, and while the first is correct, the second one is
> complete garbage -- which is ultimately what causes it to bail out with a
> vague crc or header magic mismatch error.
>
> The reason for this is that the default values in .empty_zero_page
> contain an initrd start/size and valid loader type, and while some boot
> loader and kernel configurations fix this up correctly, others do not,
> which cause the defaults to be used instead.
>
> This should fix it up, and also provide some more debugging information
> so it's more obvious how the boot params in .empty_zero_page look on
> entry.
>
> ---
>
> diff --git a/arch/sh/kernel/head_32.S b/arch/sh/kernel/head_32.S
> index d67d7ed..ae0a382 100644
> --- a/arch/sh/kernel/head_32.S
> +++ b/arch/sh/kernel/head_32.S
> @@ -30,8 +30,8 @@ ENTRY(empty_zero_page)
>        .long   0               /* RAMDISK_FLAGS */
>        .long   0x0200          /* ORIG_ROOT_DEV */
>        .long   1               /* LOADER_TYPE */
> -       .long   0x00360000      /* INITRD_START */
> -       .long   0x000a0000      /* INITRD_SIZE */
> +       .long   0x00000000      /* INITRD_START */
> +       .long   0x00000000      /* INITRD_SIZE */
>  #ifdef CONFIG_32BIT
>        .long   0x53453f00 + 32 /* "SE?" = 32 bit */
>  #else
> diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
> index 516bde9..bca2bbc 100644
> --- a/arch/sh/kernel/setup.c
> +++ b/arch/sh/kernel/setup.c
> @@ -292,6 +292,17 @@ void __init setup_arch(char **cmdline_p)
>
>        ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
>
> +       printk(KERN_NOTICE "Boot params:\n"
> +                          "... MOUNT_ROOT_RDONLY - %08lx\n"
> +                          "... RAMDISK_FLAGS     - %08lx\n"
> +                          "... ORIG_ROOT_DEV     - %08lx\n"
> +                          "... LOADER_TYPE       - %08lx\n"
> +                          "... INITRD_START      - %08lx\n"
> +                          "... INITRD_SIZE       - %08lx\n",
> +                          MOUNT_ROOT_RDONLY, RAMDISK_FLAGS,
> +                          ORIG_ROOT_DEV, LOADER_TYPE,
> +                          INITRD_START, INITRD_SIZE);
> +
>  #ifdef CONFIG_BLK_DEV_RAM
>        rd_image_start = RAMDISK_FLAGS & RAMDISK_IMAGE_START_MASK;
>        rd_prompt = ((RAMDISK_FLAGS & RAMDISK_PROMPT_FLAG) != 0);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>