Hi Jonathan,
Jonathan Pratt wrote:
Hello Mr Chief Software Dude ;-)
This isn't a big issue anymore since I have JFFS2 up & running so there
will be 16MB available for linux at startup which appears to be more
than adequate. I'd still like to know what was going on, if possible.
Hi Jonathan,
Jonathan Pratt wrote:
I'm working on an ixp425 board which was something like the
MonteJade.
The prototype boards have 32MB SDRAM populated like the
MonteJade but
we'd like to drop that down to 16MB. To test this I've altered the
specified amount of available memory on the kernel commandline. We
plan to implement JFFS2 sometime, but are currently using
the CRAMFS instead.
The size of the CRAMFS is 2.8MB compressed, just over 6
uncompressed
with the stuff we currently have in it.
(That strikes me as odd. A cramfs stores its files
compressed, I am surpised you get such good compression of a
cramfs fs...)
Forgive me if I've misunderstood something. The 6+ Mb comes from
'tar'ing the romfs directory. If this is not the final size of the fs in
No it won't be the size of a tar. You will be loading a filesystem
image. If using cramfs, as you are, then you will be loading a
complete cramfs filesystem in RAM. You don't mention how you
generate it, but almost certainly you must be using mkcramfs, and
it is the output of this that you will be loading. Whatever the
size of this file that is what you want to know here.
You don't mention how you setup the kernel, but I assume you
are using a ramdisk (with initrd)?
memory, then ... (I don't know how to figure it out). I do know that if
I allocate less than 7MB for the initrd then the mounting of the file
system causes the system to hang. The same file system image takes up
3.3MB as JFFS2 with the default compression option.
A cramfs of this would be similar in size.
Regards
Greg
This means that I can alter the size of the RAM disk on the kernel
command line to 7MB leaving 9MB for the kernel (again this is a
temporary measure). This is specified as 16M of memory at
0x00000000,
and a RAM disk of 7M at 0x00900000. Unfortuantely linux
dies after the
decompression of the kernel (I get nothing out the terminal
at all).
If I give Linux 10MB it will uncompress and run normally.
The system
dies when the filesystem is mounted if I give it less than
7MB. I've
tried putting the zImage into various RAM locations prior
to executing
it but it hasn't helped.
What address do you load the kernel at?
I've tried a number of positions - 0x00080000, 0x00400000 & 0x00C00000.
The last one was above the compressed cramfs image so that it would be
decompressed into place before the decompression of the cromfs. All of
these choices behaved the same way -> if there was less than 10MB
available the system would hang after decompression of the linux kernel.
10MB or more, then linus would decompress and run (but would hang if
there was less than 7MB for the file system.
When I run uClinux with 32M available (on the command line) and cat
/proc/meminfo, I see that there's 20MB available, with about 2M
allocated to the kernel, 3M in buffers, and the other 7M (I
presume)
used by the RAM disk.
Seems reasonable.
Does anyone know what's going on? Will uClinux always require 10MB
Well, its not "uClinux" that is using 10MB. The linux kernel
will need some space to decompress itself, and it will copy
the ramdisk in its entirety at startup before freeing the
startup image. (And this latter step is probably what is
causing you problems).
during the boot process? Is there any (easy) way to limit
this or is
it just regarded as unimportant since the memory is
apparantly freed
up afterwards anyway?
I have run 16MB images before on the ixp425. With smaller
cramfs images though (IIRC of the order of 4 to 5 MB).
As its no longer an issue, I foresee this sitting on the backburner (or
off the stove altogether :)
Regards
Greg
--------------------------------------------------------------
----------
Greg Ungerer -- Chief Software Dude EMAIL:
[EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61
7 3435 2888
825 Stanley St, FAX: +61
7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB:
http://www.SnapGear.com
Cheers
Jonathan Pratt
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
