[ELDK] U-Boot configuration kernel + rootfs squashfs image in NAND Flash, copy rootfs to ram, mount rootfs from ram

[Wolfgang Denk]

Dear Christoph,

In message <50F575DB.2000403 at gmx.de> you wrote:
>
> > Second, you write some 200+ lines of description what you did and what
> > you think, and then ask for "help or suggestions", but I cannot see
> > any clear statement of what your specific questions are,
> 
> I stated my problem in the Subject and at the beginning of my mail.

Sorry, but I disagree.  You desribe a task, i.e. what you want to do,
but you don't really state which exact parts are not working as
expected or which exact questions you want to haave answered. 

> - kernel from NAND and root file system with squashfs from ram"

But why the "from RAM" ?

> Boot and start of our main application with standard nand boot 
> configuration (Kernel + rootfsimage(Jffs2)) take around one minute.

Did you analyze where the time gets spent?  OK, JFFS2 is pretty slow,
especially when well used and when mounting larger partitions.

Did you try squashfs (or UBIFS!!) from NAND instead?

> > [1] http://catb.org/esr/faqs/smart-questions.html
> 
> Exactly which section should i read?

All of them ?

> > This makes no sense to me.  Why do you use /dev/ram here?  Your
> > squashfs file system is in NAND flash, so the normal way would be to
> > just access it through the MTD block device emulation in Linux.
> 
> Yes,this standard process works fine. I would like to find out if my 
> "unusual" configuration differs from the standard configuration with 
> respect to the boot time and application start time.

What are your expectations?  When using it from NAND, only the parts
that are really referenced will be loaded (and uncompressed) to RAM,
and you have the full RAM available for buffer cache. Things you need
only rarely or never will eventually never be loaded at all. When
using it as some form of ramdisk, you always have to load the whole
image to RAM, before you can copy (and uncompress) to another RAM
area the parts you need.

My expectation would be that this approach has to be slower, first due
to the full loading into RAM, and second to the loss of RAM space
which means everything will permanently run slower.

Your image is about 32 MB (compressed), i. e. you waste about 25% or
your RAM.  I wouldn't do that.


> > Are you sure these are correct?
> 
> It is the output of nboot. I do not know if these values are correct.

Why don't you check how the kenrel is actually configured?

> > The load address is the start address of the area where the Linux
> > kernel image gets loaded/unpacked to, and the entry point is where the
> > code execution begins (which may or may not be the very start of the
> > image).  Aren't the names pretty much self-explaining?
> 
> Yes, they are. But they do not explain in which case kernel load address 
> and kernel entry point differ.

They differ when the kernel image has it's entry point not at the very
start.  This depends on many things, including architecture, SoC,
image type, configuration, ...

> ## Loading init Ramdisk from Legacy Image at 40800000 ...
>     Image Name:   ramdisk_sqashfs
>     Image Type:   ARM Linux RAMDisk Image (uncompressed)
>     Data Size:    33755136 Bytes = 32.2 MiB
>     Load Address: 40800000
>     Entry Point:  40800000
>     Verifying Checksum ... OK
>     Loading Kernel Image ... OK

So you load the U-Boot image with your rootfs at 40800000; it starts
with the 64 byte image header, followed (at 40800040) by the raw
rootfs data. Then you perform a memcpy() of the whole image from
40800040 to 40800000.  This appears a serious waste of time to me.

> No filesystem could mount root, tried:  ext3 ext2 cramfs squashfs vfat 
> msdos iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs 
> on unknown-block(1,0) Rebooting in 1 seconds..
> 
> Why does the Kernel not find the squashfs root file system image in ram?

Sorry, we can't te;;. We don;t see the boot args that were actually
received by the Linux kernel, nor can we check which attempts the
kernel might have made to access the rootfs - from the snippets of the
boot log we cannot even guess what might have gone wrong.

> Which kernel parameters do i have to specify to have the kernel find and 
> mount the squashfs root file system image in ram?

Hm... there are a number of documents out there describing that.  Did
you try reading some? See for example http://bit.ly/13A127u

> I have squashfs, initramfs and  RAM block device support compiled into 
> the kernel.
> 
> I believe i did some thing wrong but i do not know what.

I believe you are right, but this is not enough information ...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'm what passes for a Unix guru in my office. This is  a  frightening
concept. - Lee Ann Goldstein, in <3k55ba$c43 at butch.lmsc.lockheed.com>