[U-Boot-Users] "Problem in increasing initrd(RAMDISK) size"
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
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
nreddy@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
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
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
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
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
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
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
participants (3)
-
Leif Lindholm -
nreddy＠netenrich.com -
Wolfgang Denk