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
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.

> 
> > 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
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to