ramdisk size is larger than 4MB

ramdisk size is larger than 4MB

[Shawn Jin]

Hi,

I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In
recent 2.6 kernels ramdisk is no longer supported so I decided to go
with initramfs. However I found the initial RFS for initramfs is
limited to 4MB since the bootwrapper locates at 0x400000.

One way to lift this limitation is to relocate the bootwrapper to
somewhere else, say for example, 0x1000000 so that a 16MB initramfs
can be loaded. If the bootwrapper is relocated, what else would be
affected by this relocation?

Another (better?) way may be to find a right file system for RFS such
as JFFS2. My board has limited NOR flash (32MB) but larger RAM
(128MB). There is not much space left in flash for RFS.

Would you like to share some thoughts?

Thanks a lot,
-Shawn.

Re: ramdisk size is larger than 4MB

[Scott Wood]

On Fri, 30 Jul 2010 00:00:52 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:

> Hi,
> 
> I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In
> recent 2.6 kernels ramdisk is no longer supported so I decided to go
> with initramfs. However I found the initial RFS for initramfs is
> limited to 4MB since the bootwrapper locates at 0x400000.

The uncompressed image, including both ramfs and kernel must fit below
4MB.

> One way to lift this limitation is to relocate the bootwrapper to
> somewhere else, say for example, 0x1000000 so that a 16MB initramfs
> can be loaded. If the bootwrapper is relocated, what else would be
> affected by this relocation?

It should be fine to just change it locally.  It would be a problem to
change it upstream for all boards, since some supported boards have
only 16MB (or even 8MB) of RAM.

Another option is to provide a vmlinux_alloc callback to stick the
kernel somewhere other than zero, at the cost of an extra image copy
once the kernel runs to get itself back down to zero.  This wasn't done
in cuboot because it was considered better to adjust the bootwrapper
link address at build time based on the kernel+ramfs image size, but
that never got implemented.

Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if
the image fits there, and calls malloc otherwise?

-Scott

Re: ramdisk size is larger than 4MB

[Shawn Jin]

>> One way to lift this limitation is to relocate the bootwrapper to
>> somewhere else, say for example, 0x1000000 so that a 16MB initramfs
>> can be loaded. If the bootwrapper is relocated, what else would be
>> affected by this relocation?
>
> It should be fine to just change it locally. =A0It would be a problem to
> change it upstream for all boards, since some supported boards have
> only 16MB (or even 8MB) of RAM.

I'll definitely try to change it locally first. Would a configurable
base address for the bootwrapper an acceptable solution?

> Another option is to provide a vmlinux_alloc callback to stick the
> kernel somewhere other than zero, at the cost of an extra image copy
> once the kernel runs to get itself back down to zero. =A0This wasn't done
> in cuboot because it was considered better to adjust the bootwrapper
> link address at build time based on the kernel+ramfs image size, but
> that never got implemented.
>
> Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if
> the image fits there, and calls malloc otherwise?

I'll look into this too.

Thanks,
-Shawn.

Re: ramdisk size is larger than 4MB

[Shawn Jin]

>> It should be fine to just change it locally. =A0It would be a problem to
>> change it upstream for all boards, since some supported boards have
>> only 16MB (or even 8MB) of RAM.
>
> I'll definitely try to change it locally first. Would a configurable
> base address for the bootwrapper an acceptable solution?

I found the link_address in the wrapper shell script sets the _start
address. But after changing it to 0x800000, the kernel failed to boot,
shown below. There must be something also needs proper adjustment.
What would that be?

=3D> bootm 4000000
## Booting image at 04000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1757356 Bytes =3D  1.7 MB
   Load Address: 00800000
   Entry Point:  00800554
   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 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=3D/dev/ram
Finalizing device tree... flat tree at 0xbe4300

Thanks a lot,
-Shawn.

Re: ramdisk size is larger than 4MB

[Shawn Jin]

> I found the link_address in the wrapper shell script sets the _start
> address. But after changing it to 0x800000, the kernel failed to boot,
> shown below. There must be something also needs proper adjustment.
> What would that be?

I did more debugging and something is really weird though. When the
link address is changed to 0x800000, when stepping through the kernel,
I actually got the kernel boot successfully. However I let the kernel
run through it would just crash. After crash the BDI2000 shows it
stopped at __delay().

I also changed the link address to 0x4000000. During the function
of_scan_flat_dt(early_init_dt_scan_chosen, NULL) called in
early_init_devtree(), gdb shows the program (i.e. kernel) received a
signal SIGSTOP.

Why would the kernel crash during that time? of_scan_flat_dt() doesn't
seem to be the cause of SIGSTOP. What would that be then?

Thanks,
-Shawn.

Re: ramdisk size is larger than 4MB

[Shawn Jin]

> I did more debugging and something is really weird though. When the
> link address is changed to 0x800000, when stepping through the kernel,
> I actually got the kernel boot successfully. However I let the kernel
> run through it would just crash. After crash the BDI2000 shows it
> stopped at __delay().

Well, actually it's nothing to do with gdb.

When the link address is changed to 0x800000, if the PPC_EARLY_DEBUG
and PPC_EARLY_DEBUG_CPM are on, the built kernel can boot
successfully. But without these EARLY_DEBUG, the kernel fails to boot.

=> bootm 5000000
## Booting image at 05000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1757354 Bytes =  1.7 MB
   Load Address: 00800000
   Entry Point:  00800554
   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 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
^^^^^^^^^^^^^^^^^^The kernel stopped here.

=> bootm 5000000
## Booting image at 05000000 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1757742 Bytes =  1.7 MB
   Load Address: 00800000
   Entry Point:  00800554
   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 0x00800000 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using My MPC870 machine description
Linux version 2.6.33.5 (shanw@ubuntu) (gcc version 4.2.2) #5 Tue Aug 3
21:24:40 PDT 2010
bootconsole [udbg0] enabled
^^^^^^^^^The kernel continued booting.

With the EARLY_DEBUG turned on, the link address is changed to
0x1000000, the built kernel can also boot successfully.

However if the link address is changed to 0x2000000 or 0x4000000, the
built kernel fails to boot.

I think the kernel failure may be caused by some memory corruption.
But will the bootwrapper relocation corrupt the kernel code?

Thanks,
-Shawn.