cuImage and multi image?

cuImage and multi image?

[Shawn Jin]

Hi,

I have a cuImage kernel in order to support legacy u-boot and a
ramdisk image. Kernel boots fine if these two images are separate and
"bootm $kernel $ramdisk" is used. But I can not make it to work using
a single multi image that contains the kernel and ramdisk images. Is
it even technically possible to boot a multi-image with cuboot
wrapper?

On the cuImage kernel I have load address set to 0x400000 and the
entry address set to 0x400554 due to the cuboot wrapper. But to make a
multi image, both the load and the entry addresses should be set to
zero. And u-boot (1.1.2) bootm takes the entry address of the multi
image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the
entry address for a cuImage kernel.

Is there a possible workaround other than using two separate images?

Thanks,
-Shawn.

Re: cuImage and multi image?

[tiejun.chen]

Shawn Jin wrote:
> Hi,
> 
> I have a cuImage kernel in order to support legacy u-boot and a
> ramdisk image. Kernel boots fine if these two images are separate and
> "bootm $kernel $ramdisk" is used. But I can not make it to work using
> a single multi image that contains the kernel and ramdisk images. Is
> it even technically possible to boot a multi-image with cuboot
> wrapper?

Try the following steps:
------
1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
2. make cuImage.initrd.<your target>

You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.

Cheers
Tiejun

> 
> On the cuImage kernel I have load address set to 0x400000 and the
> entry address set to 0x400554 due to the cuboot wrapper. But to make a
> multi image, both the load and the entry addresses should be set to
> zero. And u-boot (1.1.2) bootm takes the entry address of the multi
> image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the
> entry address for a cuImage kernel.
> 
> Is there a possible workaround other than using two separate images?
> 
> Thanks,
> -Shawn.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

Re: cuImage and multi image?

[Shawn Jin]

> Try the following steps:
> ------
> 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.<your target>
>
> You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.

Cool! Thanks a lot, Tiejun.

-Shawn.

Re: cuImage and multi image?

[Shawn Jin]

>> I have a cuImage kernel in order to support legacy u-boot and a
>> ramdisk image. Kernel boots fine if these two images are separate and
>> "bootm $kernel $ramdisk" is used. But I can not make it to work using
>> a single multi image that contains the kernel and ramdisk images. Is
>> it even technically possible to boot a multi-image with cuboot
>> wrapper?
>
> Try the following steps:
> ------
> 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.<your target>
>
> You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.

A follow up question. With this method, the total image size
(uncompressed) is limited to the 4MB (the link address of the boot
wrapper)?

Thanks,
-Shawn.

RE: cuImage and multi image?

[Chen, Tiejun]

> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Tuesday, September 21, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: cuImage and multi image?
>=20
> >> I have a cuImage kernel in order to support legacy u-boot and a=20
> >> ramdisk image. Kernel boots fine if these two images are=20
> separate and=20
> >> "bootm $kernel $ramdisk" is used. But I can not make it to=20
> work using=20
> >> a single multi image that contains the kernel and ramdisk=20
> images. Is=20
> >> it even technically possible to boot a multi-image with cuboot=20
> >> wrapper?
> >
> > Try the following steps:
> > ------
> > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > 2. make cuImage.initrd.<your target>
> >
> > You can get one Image, cuImage.initrd.<your target>,=20
> including kernel and ramdisk.
>=20
> A follow up question. With this method, the total image size
> (uncompressed) is limited to the 4MB (the link address of the=20
> boot wrapper)?

No.

Cheers
Tiejun

>=20
> Thanks,
> -Shawn.
>=20

Re: [U-Boot] cuImage and multi image?

[Scott Wood]

On Tue, 21 Sep 2010 03:03:22 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:

> > -----Original Message-----
> > From: Shawn Jin [mailto:shawnxjin@gmail.com] 
> > Sent: Tuesday, September 21, 2010 1:53 AM
> > To: Chen, Tiejun
> > Cc: ppcdev; uboot
> > Subject: Re: cuImage and multi image?
> > 
> > >> I have a cuImage kernel in order to support legacy u-boot and a 
> > >> ramdisk image. Kernel boots fine if these two images are 
> > separate and 
> > >> "bootm $kernel $ramdisk" is used. But I can not make it to 
> > work using 
> > >> a single multi image that contains the kernel and ramdisk 
> > images. Is 
> > >> it even technically possible to boot a multi-image with cuboot 
> > >> wrapper?
> > >
> > > Try the following steps:
> > > ------
> > > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > > 2. make cuImage.initrd.<your target>
> > >
> > > You can get one Image, cuImage.initrd.<your target>, 
> > including kernel and ramdisk.
> > 
> > A follow up question. With this method, the total image size
> > (uncompressed) is limited to the 4MB (the link address of the 
> > boot wrapper)?
> 
> No.

Yes, unless you change the link address, or provide a vmlinux_alloc
callback (which currently only happens on true OF, not cuImage).

Unless you're talking about the "(uncompressed)"?  The limit applies to
the uncompressed boot image -- anything that the bootwrapper itself is
decompressing.  It does not apply to any further uncompression of the
ramdisk itself.

-Scott

RE: [U-Boot] cuImage and multi image?

[Chen, Tiejun]

> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+tiejun.chen=3Dwindriver.com@lists.ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+tiejun.chen=3Dwindriver.com@lists.o
zlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, September 22, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: [U-Boot] cuImage and multi image?
>=20
> On Tue, 21 Sep 2010 03:03:22 +0200
> "Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
>=20
> > > -----Original Message-----
> > > From: Shawn Jin [mailto:shawnxjin@gmail.com]
> > > Sent: Tuesday, September 21, 2010 1:53 AM
> > > To: Chen, Tiejun
> > > Cc: ppcdev; uboot
> > > Subject: Re: cuImage and multi image?
> > >=20
> > > >> I have a cuImage kernel in order to support legacy=20
> u-boot and a=20
> > > >> ramdisk image. Kernel boots fine if these two images are
> > > separate and
> > > >> "bootm $kernel $ramdisk" is used. But I can not make it to
> > > work using
> > > >> a single multi image that contains the kernel and ramdisk
> > > images. Is
> > > >> it even technically possible to boot a multi-image with cuboot=20
> > > >> wrapper?
> > > >
> > > > Try the following steps:
> > > > ------
> > > > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > > > 2. make cuImage.initrd.<your target>
> > > >
> > > > You can get one Image, cuImage.initrd.<your target>,
> > > including kernel and ramdisk.
> > >=20
> > > A follow up question. With this method, the total image size
> > > (uncompressed) is limited to the 4MB (the link address of=20
> the boot=20
> > > wrapper)?
> >=20
> > No.
>=20
> Yes, unless you change the link address, or provide a=20
> vmlinux_alloc callback (which currently only happens on true=20
> OF, not cuImage).
>=20
> Unless you're talking about the "(uncompressed)"?  The limit=20
> applies to the uncompressed boot image -- anything that the=20
> bootwrapper itself is decompressing.  It does not apply to=20
> any further uncompression of the ramdisk itself.
>=20

He should point the latter, "the total image size", including ramdisk.
But the link address should be limited for the boot Image, not for the
attached ramdisk.

Tiejun

> -Scott
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20

Re: [U-Boot] cuImage and multi image?

[Shawn Jin]

>> > > A follow up question. With this method, the total image size
>> > > (uncompressed) is limited to the 4MB (the link address of
>> the boot
>> > > wrapper)?
>> >
>> > No.
>>
>> Yes, unless you change the link address, or provide a
>> vmlinux_alloc callback (which currently only happens on true
>> OF, not cuImage).
>>
>> Unless you're talking about the "(uncompressed)"? =A0The limit
>> applies to the uncompressed boot image -- anything that the
>> bootwrapper itself is decompressing. =A0It does not apply to
>> any further uncompression of the ramdisk itself.
>>
>
> He should point the latter, "the total image size", including ramdisk.
> But the link address should be limited for the boot Image, not for the
> attached ramdisk.

Thanks for the clarification. Scott, so what are the things that the
bootwrapper is decompressing? The kernel for sure. And anything else?
I understand that the ramdisk image will be decompressed later when
trying to boot it.

I have a large ramdisk image. The size of the image itself (i.e. the
*.gz) is about 4MB. When the ramdisk was being decompressed in the
later stage. It had the following errors. It seems to me that the
ramdisk image somehow was corrupted. Did the script wrapper mess up
the image? Is there any known bug in the wrapper? My kernel is 2.6.33.
BTW the ramdisk image can be mounted properly if it's separated from
the kernel image.

RAMDISK: gzip image found at block 0
uncompression error
VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
Freeing unused kernel memory: 104k init
EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
rec_len is smaller than minimal - offset=3D0, inode=3D0, rec_len=3D0,
name_len=3D0
EXT2-fs (ram0): error: remounting filesystem read-only
Kernel panic - not syncing: No init found.  Try passing init=3D option to k=
ernel.
Call Trace:
[c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)
[c7821f70] [c001cefc] panic+0x8c/0x178
[c7821fc0] [c00026d4] init_post+0xe4/0xf4
[c7821fd0] [c01ee224] kernel_init+0x108/0x130
[c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

Thanks,
-Shawn.

RE: [U-Boot] cuImage and multi image?

[Chen, Tiejun]

> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Wednesday, September 22, 2010 1:43 PM
> To: Chen, Tiejun
> Cc: Scott Wood; ppcdev; uboot
> Subject: Re: [U-Boot] cuImage and multi image?
>=20
> >> > > A follow up question. With this method, the total image size
> >> > > (uncompressed) is limited to the 4MB (the link address of
> >> the boot
> >> > > wrapper)?
> >> >
> >> > No.
> >>
> >> Yes, unless you change the link address, or provide a=20
> vmlinux_alloc=20
> >> callback (which currently only happens on true OF, not cuImage).
> >>
> >> Unless you're talking about the "(uncompressed)"? =A0The=20
> limit applies=20
> >> to the uncompressed boot image -- anything that the bootwrapper=20
> >> itself is decompressing. =A0It does not apply to any further=20
> >> uncompression of the ramdisk itself.
> >>
> >
> > He should point the latter, "the total image size",=20
> including ramdisk.
> > But the link address should be limited for the boot Image,=20
> not for the=20
> > attached ramdisk.
>=20
> Thanks for the clarification. Scott, so what are the things=20
> that the bootwrapper is decompressing? The kernel for sure.=20
> And anything else?

I think you can read the file, arch/powerpc/boot/zImage.lds.S, to =
understand this :)

> I understand that the ramdisk image will be decompressed=20
> later when trying to boot it.
>=20
> I have a large ramdisk image. The size of the image itself (i.e. the
> *.gz) is about 4MB. When the ramdisk was being decompressed=20

Did you try to change link_address on the file, =
arch/powerpc/boot/wrapper?

> in the later stage. It had the following errors. It seems to=20
> me that the ramdisk image somehow was corrupted. Did the=20
> script wrapper mess up the image? Is there any known bug in=20
> the wrapper? My kernel is 2.6.33.

I tried this mechanism on v2.6.34 and it's fine.

> BTW the ramdisk image can be mounted properly if it's=20
> separated from the kernel image.
>=20

Did you try boot the uImage and the ramdisk separately? For example, you =
can boot this as the following command:
# bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}

Please use this to check if your ramdisk is valid.

Can you paste the whole log from the u-boot prompt?

Tiejun

> RAMDISK: gzip image found at block 0
> uncompression error
> VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
> Freeing unused kernel memory: 104k init
> EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
> rec_len is smaller than minimal - offset=3D0, inode=3D0,=20
> rec_len=3D0, name_len=3D0 EXT2-fs (ram0): error: remounting=20
> filesystem read-only Kernel panic - not syncing: No init=20
> found.  Try passing init=3D option to kernel.
> Call Trace:
> [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)=20
> [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4]=20
> init_post+0xe4/0xf4 [c7821fd0] [c01ee224]=20
> kernel_init+0x108/0x130 [c7821ff0] [c000dcc0]=20
> kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
>=20
> Thanks,
> -Shawn.
>=20

Re: [U-Boot] cuImage and multi image?

[Shawn Jin]

>> I have a large ramdisk image. The size of the image itself (i.e. the
>> *.gz) is about 4MB. When the ramdisk was being decompressed
>
> Did you try to change link_address on the file, arch/powerpc/boot/wrapper?

No. I don't have to. Right? The link_address is still 0x400000.

> Did you try boot the uImage and the ramdisk separately? For example, you can boot this as the following command:
> # bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}

Mine is a cuImage. I'm pretty sure that my ramdisk is valid when it's
a separate image. I used "bootm <kernel_addr> <ramdisk_addr>" to boot.

> Can you paste the whole log from the u-boot prompt?

In the previous run the ramdisk image was corrupted because the single
image was loaded at 0x800000. But the boot message showed that the
initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB
area.

However after the load address was changed to 0x04000000 (64MB), the
ramdisk still seemed corrupted but with different error messages.

=> bootm
## Booting image at 04000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    4424922 Bytes =  4.2 MB
   Load Address: 00400000
   Entry Point:  00400554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)

zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)
Allocating 0x22a1e1 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes
Attached initrd image at 0x0066c000-0x009ae825
initrd head: 0x1f8b0808

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0x9bb300
Using my870 machine description
Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep
21 09:23:51 PDT 2010
Found initrd at 0xc066c000:0xc09ae825
Zone PFN ranges:
  DMA      0x00000000 -> 0x00008000
  Normal   0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00008000
MMU: Allocated 72 bytes of context maps for 16 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/ram
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 124072k/131072k available (2080k kernel code, 6836k reserved,
84k data, 52k bss, 104k init)
Kernel virtual memory layout:
  * 0xfffdf000..0xfffff000  : fixmap
  * 0xfde00000..0xfe000000  : consistent mem
  * 0xfddfa000..0xfde00000  : early ioremap
  * 0xc9000000..0xfddfa000  : vmalloc & ioremap
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
....
<snipped>
....
RAMDISK: gzip image found at block 0
uncompression error
VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
Freeing unused kernel memory: 104k init
EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
unaligned directory entry - offset=0, inode=74187384, rec_len=2081,
name_len=126
EXT2-fs (ram0): error: remounting filesystem read-only
attempt to access beyond end of device
ram0: rw=0, want=156831968, limit=32768
Buffer I/O error on device ram0, logical block 78415983
attempt to access beyond end of device
ram0: rw=0, want=112233212, limit=32768
Buffer I/O error on device ram0, logical block 56116605
attempt to access beyond end of device
ram0: rw=0, want=6626681482, limit=32768
Buffer I/O error on device ram0, logical block 3313340740
attempt to access beyond end of device
ram0: rw=0, want=184684282, limit=32768
Buffer I/O error on device ram0, logical block 92342140
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
Call Trace:
[c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)
[c7821f70] [c001cefc] panic+0x8c/0x178
[c7821fc0] [c00026d4] init_post+0xe4/0xf4
[c7821fd0] [c01ee224] kernel_init+0x108/0x130
[c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

Thanks,
-Shawn.

Re: [U-Boot] cuImage and multi image?

[Shawn Jin]

>> Can you paste the whole log from the u-boot prompt?
>
> In the previous run the ramdisk image was corrupted because the single
> image was loaded at 0x800000. But the boot message showed that the
> initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB
> area.
>
> However after the load address was changed to 0x04000000 (64MB), the
> ramdisk still seemed corrupted but with different error messages.
>
> =3D> bootm
> ## Booting image at 04000000 ...
> =A0 Image Name: =A0 Linux-2.6.33.5
> =A0 Image Type: =A0 PowerPC Linux Kernel Image (gzip compressed)
> =A0 Data Size: =A0 =A04424922 Bytes =3D =A04.2 MB
> =A0 Load Address: 00400000
> =A0 Entry Point: =A000400554
> =A0 Verifying Checksum ... OK
> =A0 Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x8000000> (128MB)
> ENET0: local-mac-address <- 00:09:9b:01:58:64
> CPU clock-frequency <- 0x7270e00 (120MHz)
> CPU timebase-frequency <- 0x7270e0 (8MHz)
> CPU bus-frequency <- 0x3938700 (60MHz)
>
> zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)
> Allocating 0x22a1e1 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes
> Attached initrd image at 0x0066c000-0x009ae825
> initrd head: 0x1f8b0808
>
> Linux/PowerPC load: root=3D/dev/ram
> Finalizing device tree... flat tree at 0x9bb300
> Using my870 machine description
> Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep
> 21 09:23:51 PDT 2010
> Found initrd at 0xc066c000:0xc09ae825

The following shows the boot message that the same kernel and the same
ramdisk were loaded separately. The difference is that when boot from
two separate images, the ramdisk is loaded to the top of RAM
(0x79d9000-0x7d1b825). While when booting from the single image, the
ramdisk is loaded to the place immediately after the uncompressed
kernel image (0x0066c000-0x009ae825). I'm not familiar with how the
kernel uses the memory. But it seems clear from this failure that the
kernel overwrites to where the initrd locates.

Anyone can shed some light on why the kernel would overwrite the
initrd area? BTW, if the initrd is small enough, the single image
method works well. Maybe we should have relocated the initrd to the
top of available ram just like u-boot's bootm?

=3D> bootm 1000000 2000000
## Booting image at 01000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1040228 Bytes =3D 1015.8 kB
   Load Address: 00400000
   Entry Point:  00400554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
   Image Name:   16MB Ramdisk
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    3418149 Bytes =3D  3.3 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 079d9000, end 07d1b825 ... OK
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x7270e0 (8MHz)
CPU bus-frequency <- 0x3938700 (60MHz)

zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)
Allocating 0x22a1e1 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes
Using loader supplied ramdisk at 0x79d9000-0x7d1b825
initrd head: 0x1f8b0808

Linux/PowerPC load: root=3D/dev/ram
Finalizing device tree... flat tree at 0x678300
Using my870 machine description
Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep
21 09:23:51 PDT 2010
Found initrd at 0xc79d9000:0xc7d1b825

Thanks,
-Shawn.

RE: [U-Boot] cuImage and multi image?

[Chen, Tiejun]

> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Thursday, September 23, 2010 4:23 AM
> To: Chen, Tiejun
> Cc: Scott Wood; ppcdev; uboot
> Subject: Re: [U-Boot] cuImage and multi image?
>=20
> >> I have a large ramdisk image. The size of the image itself=20
> (i.e. the
> >> *.gz) is about 4MB. When the ramdisk was being decompressed
> >
> > Did you try to change link_address on the file,=20
> arch/powerpc/boot/wrapper?
>=20
> No. I don't have to. Right? The link_address is still 0x400000.

I means you can change link_address to other value according to the
Image size. Try set link_address=3D'0x5000000'.

>=20
> > Did you try boot the uImage and the ramdisk separately? For=20
> example, you can boot this as the following command:
> > # bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
>=20
> Mine is a cuImage. I'm pretty sure that my ramdisk is valid=20
> when it's a separate image. I used "bootm <kernel_addr>=20
> <ramdisk_addr>" to boot.
>=20
> > Can you paste the whole log from the u-boot prompt?
>=20
> In the previous run the ramdisk image was corrupted because=20
> the single image was loaded at 0x800000. But the boot message=20
> showed that the initrd image was at 0x0066c000-0x009ae825. So=20
> it was over the 8MB area.
>=20
> However after the load address was changed to 0x04000000=20
> (64MB), the ramdisk still seemed corrupted but with different=20
> error messages.

This should be the same reason, 'uncompression error'.

Cheers
Tiejun

>=20
> =3D> bootm
> ## Booting image at 04000000 ...
>    Image Name:   Linux-2.6.33.5
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    4424922 Bytes =3D  4.2 MB
>    Load Address: 00400000
>    Entry Point:  00400554
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x8000000> (128MB)
> ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU=20
> clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency=20
> <- 0x7270e0 (8MHz) CPU bus-frequency <- 0x3938700 (60MHz)
>=20
> zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0)=20
> Allocating 0x22a1e1 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done=20
> 0x21c6c8 bytes Attached initrd image at 0x0066c000-0x009ae825=20
> initrd head: 0x1f8b0808
>=20
> Linux/PowerPC load: root=3D/dev/ram
> Finalizing device tree... flat tree at 0x9bb300 Using my870=20
> machine description Linux version 2.6.33.5 (shawn@ubuntu)=20
> (gcc version 4.2.2) #4 Tue Sep
> 21 09:23:51 PDT 2010
> Found initrd at 0xc066c000:0xc09ae825
> Zone PFN ranges:
>   DMA      0x00000000 -> 0x00008000
>   Normal   0x00008000 -> 0x00008000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0: 0x00000000 -> 0x00008000
> MMU: Allocated 72 bytes of context maps for 16 contexts Built=20
> 1 zonelists in Zone order, mobility grouping on.  Total=20
> pages: 32512 Kernel command line: root=3D/dev/ram PID hash=20
> table entries: 512 (order: -1, 2048 bytes) Dentry cache hash=20
> table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash=20
> table entries: 8192 (order: 3, 32768 bytes)
> Memory: 124072k/131072k available (2080k kernel code, 6836k=20
> reserved, 84k data, 52k bss, 104k init) Kernel virtual memory layout:
>   * 0xfffdf000..0xfffff000  : fixmap
>   * 0xfde00000..0xfe000000  : consistent mem
>   * 0xfddfa000..0xfde00000  : early ioremap
>   * 0xc9000000..0xfddfa000  : vmalloc & ioremap
> SLUB: Genslabs=3D12, HWalign=3D16, Order=3D0-3, MinObjects=3D0,=20
> CPUs=3D1, Nodes=3D1 ....
> <snipped>
> ....
> RAMDISK: gzip image found at block 0
> uncompression error
> VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
> Freeing unused kernel memory: 104k init
> EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
> unaligned directory entry - offset=3D0, inode=3D74187384, =
rec_len=3D2081,
> name_len=3D126
> EXT2-fs (ram0): error: remounting filesystem read-only=20
> attempt to access beyond end of device
> ram0: rw=3D0, want=3D156831968, limit=3D32768
> Buffer I/O error on device ram0, logical block 78415983=20
> attempt to access beyond end of device
> ram0: rw=3D0, want=3D112233212, limit=3D32768
> Buffer I/O error on device ram0, logical block 56116605=20
> attempt to access beyond end of device
> ram0: rw=3D0, want=3D6626681482, limit=3D32768 Buffer I/O error on=20
> device ram0, logical block 3313340740 attempt to access=20
> beyond end of device
> ram0: rw=3D0, want=3D184684282, limit=3D32768
> Buffer I/O error on device ram0, logical block 92342140=20
> Kernel panic - not syncing: No init found.  Try passing init=3D=20
> option to kernel.
> Call Trace:
> [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)=20
> [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4]=20
> init_post+0xe4/0xf4 [c7821fd0] [c01ee224]=20
> kernel_init+0x108/0x130 [c7821ff0] [c000dcc0]=20
> kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
>=20
> Thanks,
> -Shawn.
>=20