[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[nreddy at netenrich.com]

Hi All,

I am struggling  with RAM disk Space.

My Problem is :

I am working on a emebdded system(WALNUT405 board based ).In the first
version of the system we have 16MB SDRAM, executing Linux OS(Embedded
Linux Kernel from Montavista ).It was working fine.

Later we have upgraded SDRAM size to 32MB to include more libraries in the
file system.

Here "initrd(linux file system)" includes all my application code along
with linux file system.

Inorder to include some more features in the application ,we need to
increase the initrd size(RAMDISK size).

Currently our RAMDISK size is 4MB and it is working fine.
We wanted to increase  RAMDISK size to 16MB.

   Is there any relationship that we need to takecare in the kernel to
accomidate this RAMDISK size change.

   We tried by changing the RAMDISK size to 8MB, without any modifications
in Kernel, which worked fine. But when we increased the RAM DISK to
more than 8MB(12or16MB), the kernel is giving "Kernel panic" error.

Can some body throw a light to increase the RAMDISK size.

Thanks in Advance,
Nagi Reddy

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Wolfgang Denk]

In message <33621.202.62.67.130.1118214038.squirrel@202.62.67.130> you wrote:
> 
> I am struggling  with RAM disk Space.

And what has this to do with U-Boot?

> Here "initrd(linux file system)" includes all my application code along
> with linux file system.

Using a  ramdisk  for  the  root  file  system  is  nearly  always  a
sub-optimal  solution. It's OK for quick testing, but not a good idea
for production systems.

> Currently our RAMDISK size is 4MB and it is working fine.
> We wanted to increase  RAMDISK size to 16MB.

Just do it. All this is documented, and actually even part of the FAQ list:
http://www.denx.de/twiki/bin/view/DULG/HowToIncreaseSizeOfRamdisk

>    We tried by changing the RAMDISK size to 8MB, without any modifications
> in Kernel, which worked fine. But when we increased the RAM DISK to
> more than 8MB(12or16MB), the kernel is giving "Kernel panic" error.

Sorry, but this is completely off topic on this list.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cogito cogito ergo cogito sum - "I think that I  think,  therefore  I
think that I am."          - Ambrose Bierce, "The Devil's Dictionary"

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Leif Lindholm]

nreddy at netenrich.com wrote:
> Hi All,
> 
> I am struggling  with RAM disk Space.
...
> Can some body throw a light to increase the RAMDISK size.

There is a hard limitation in u-boot, causing "bootm" command to
silently fail gunzip with images having an uncompressed size of > 4Mb.

In file cmd_bootm.c, function do_bootm(), the line
        uint    unc_len = 0x400000;
specifies the maximum size of the output buffer.

The ugly fix would be to just increase this value (like I did).

Of course, if this doesn't solve your problem, Wolfgang is correct and
your question belongs on a different mailing list.

regards
	/
		Leif

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Wolfgang Denk]

Dear Leif,

in message <42A6B3BA.7000502@i3micro.com> you wrote:
>
> > Can some body throw a light to increase the RAMDISK size.
> 
> There is a hard limitation in u-boot, causing "bootm" command to
> silently fail gunzip with images having an uncompressed size of > 4Mb.

This has NOTHING to do with ramdisk sizes.

U-Boot does not uncompress ramdisk images, this is done by the  Linux
kernel.  U-Boot  just  (loads  and) passes the address of the ramdisk
image to the Linux kernel without touching the data at all.

> The ugly fix would be to just increase this value (like I did).

No such change is needed (unless you end up with a Linux kernel  that
does not fit in 4 MB any more).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Leif Lindholm]

Wolfgang Denk wrote:
>>There is a hard limitation in u-boot, causing "bootm" command to
>>silently fail gunzip with images having an uncompressed size of > 4Mb.
> 
> This has NOTHING to do with ramdisk sizes.
>
> U-Boot does not uncompress ramdisk images, this is done by the  Linux
> kernel.  U-Boot  just  (loads  and) passes the address of the ramdisk
> image to the Linux kernel without touching the data at all.
> 
>>The ugly fix would be to just increase this value (like I did).
> 
> No such change is needed (unless you end up with a Linux kernel  that
> does not fit in 4 MB any more).

Well, this is probably true in more sane cases, but when using embedded
ramdisk image (available for both mips and ppc I believe), the 4Mb
u-boot limit can indeed cause problems.

Yes I know everyone's supposed to upgrade to 2.6 and initramfs.

/
	Leif

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Wolfgang Denk]

In message <42A6E116.7090906@i3micro.com> you wrote:
>
> > No such change is needed (unless you end up with a Linux kernel  that
> > does not fit in 4 MB any more).
> 
> Well, this is probably true in more sane cases, but when using embedded
> ramdisk image (available for both mips and ppc I believe), the 4Mb
> u-boot limit can indeed cause problems.

No, it CANNOT.

I repeat: U-Boot does NOT uncompress  the  ramdisk.  It  just  passes
information  about  the ramdisk as is (i. e. compressed) to the Linux
kernel. It is the Linux kernel  which  uncompresses  the  ramdisk  if
necessary.


> Yes I know everyone's supposed to upgrade to 2.6 and initramfs.

I disagree.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How come everyone's going so slow if it's called rush hour?

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Leif Lindholm]

Wolfgang Denk wrote:
>>Well, this is probably true in more sane cases, but when using embedded
>>ramdisk image (available for both mips and ppc I believe), the 4Mb
>>u-boot limit can indeed cause problems.
> 
> No, it CANNOT.

Yes it CAN.

> I repeat: U-Boot does NOT uncompress  the  ramdisk.  It  just  passes
> information  about  the ramdisk as is (i. e. compressed) to the Linux
> kernel. It is the Linux kernel  which  uncompresses  the  ramdisk  if
> necessary.

The "embedded ramdisk image" option causes the ramdisk.gz (objcopied to
ramdisk.o) to be linked into vmlinux.
When using a 16Mb filesystem, if even somewhat filled, the likelihood of
the image size growing beyond 4Mb is quite large.

Yes, this is actually a braindead enough solution that the ramdisk is
compressed _twice_, but on the mips (2.4 series Linux), embedded ramdisk
has been so widely used that noone seems to have noticed that regular
initrd support is broken. This is fixed for 2.6 though.

/
	Leif

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Wolfgang Denk]

Dear Leif,

in message <42A6F777.20801@i3micro.com> you wrote:
>
> Yes it CAN.

Ummm...

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

> The "embedded ramdisk image" option causes the ramdisk.gz (objcopied to
> ramdisk.o) to be linked into vmlinux.
> When using a 16Mb filesystem, if even somewhat filled, the likelihood of
> the image size growing beyond 4Mb is quite large.

The fact that you can do such a thing does not mean  that  it'a  s  a
good  idea. I've never been a friend of the embedded ramdisk feature,
but my view is resource oriented and I just have to accept that  it's
a  cleaner  design  than to copy things that can be done in user land
into kernel code. But then  -  this  is  intended  to  bootstrap  the
system, and NOT to provide a root file system with application code.

You're almost certainly running a sub-optimal design if you're  using
a  ramdisk  anyway - ther eis neraly always much better solutions, no
matter if your optimization criteria are memory footprint, boot time,
or what.

> Yes, this is actually a braindead enough solution that the ramdisk is
> compressed _twice_, but on the mips (2.4 series Linux), embedded ramdisk
> has been so widely used that noone seems to have noticed that regular
> initrd support is broken. This is fixed for 2.6 though.

I don't know which kernel tree you are talking about. On the few MIPS
boards we support ramdisk support is working fine.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"An open mind has but one disadvantage: it collects dirt."
                                                    - a saying at RPI

[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"

[Leif Lindholm]

Wolfgang Denk wrote:
>>Yes, this is actually a braindead enough solution that the ramdisk is
>>compressed _twice_, but on the mips (2.4 series Linux), embedded ramdisk
>>has been so widely used that noone seems to have noticed that regular
>>initrd support is broken. This is fixed for 2.6 though.
> 
> I don't know which kernel tree you are talking about. On the few MIPS
> boards we support ramdisk support is working fine.

Just for the record/mailing list archive:
Initrd support for linux-mips.org CVS, 2.4 branch, is hard-coded for
embedded ramdisk in au1000/common/setup.c

Hence, normal ramdisk support does not work on 2.4 for any of the au1xxx
boards.

/
	Leif