Not having to copy ramdisk.gz from flash to RAM

Andrew Armstrong andrewa at ovation.co.uk
Fri Aug 10 10:45:07 CDT 2007


Its probably not worth the hassle with the kernel image.

To get a real saving, look at the assembler generated for the cp.l
command, there is a load of junk there doing alignment checks. If you
can do some inline assember to replace that, you could at least double
the performance of the routine.

Andrew

On Fri, 2007-08-10 at 08:39 -0700, Andy Ngo wrote:
> Thanks.  Is the same true for the kernel image?  Let's say that space
> on the NOR flash is not an issue; if I have an uncompressed kernel
> image (I believe uImage is compressed now), will it boot a little
> faster?
> 
> Thanks.
> 
> Regards,
> Andy
> 
> ----- Original Message ----
> From: Andrew Armstrong <andrewa at ovation.co.uk>
> To: Andy Ngo <ndno72-davinci at yahoo.com>
> Cc: Roberto Waltman <rwaltman at electrophysics.com>;
> "davinci-linux-open-source @linux.davincidsp.com"
> <davinci-linux-open-source at linux.davincidsp.com>
> Sent: Friday, August 10, 2007 8:14:37 AM
> Subject: Re: Not having to copy ramdisk.gz from flash to RAM
> 
> Andy,
> 
> Through my own tests, I find a large uncompressed image copy is way
> way
> faster than a compressed one with a decompress stage.
> 
> It is worth doing if you can fit it in your NOR. (make sure you se
> cp.l
> rather an cp.b in UBOOT!)
> 
> Regards,
> 
> Andrew
> 
> On Fri, 2007-08-10 at 08:10 -0700, Andy Ngo wrote:
> > Thanks for the response.  That makes sense.  Short of hacking the
> > kernel to do what I want, I just have to stick with this and find
> > other ways of improving the boot up time.  If I use a non-compressed
> > image (ramdisk instead of ramdisk.gz), will it buy me much time?  By
> > that I mean copy time < uncompressing time?
> > 
> > Thanks.
> > 
> > Regards,
> > Andy
> > 
> > ----- Original Message ----
> > From: Roberto Waltman <rwaltman at electrophysics.com>
> > To: "davinci-linux-open-source @linux.davincidsp.com"
> > <davinci-linux-open-source at linux.davincidsp.com>
> > Sent: Friday, August 10, 2007 7:48:55 AM
> > Subject: Re: Not having to copy ramdisk.gz from flash to RAM
> > 
> > Andy Ngo wrote:
> > > ...
> > > ... Why does the ramdisk.gz image have to be in RAM first; isn't
> the
> > > kernel going to "uncompress" it to another part of RAM anyways; if
> > so,
> > > why can't it "uncompress" the ramdisk.gz directly from flash to
> > RAM ...
> > My answer is only an "educated guess", treat it accordingly. I
> assume
> > that is to make the kernel and booting process more simple and
> > consistent by dealing with one case only: ramdisk.gz is already in
> > memory, expand it an use it from here.
> > 
> > Otherwise the kernel would have to know how to directly handle any
> one
> > of today's various memory architectures, plus anything the future
> may
> > bring.
> > For example, the ramdisk image could be stored in NOR FLASH chips,
> > ("plain memory", address + data), NAND FLASH chips, (more of a block
> > device, you provide commands and read/write blocks of data), I2C
> > EEPROMS
> > (read a bitstream), etc.
> > 
> > It makes sense from a design perspective to have the bootloader,
> (that
> > needs to be customized for a particular hardware platform anyhow,)
> > take
> > care of these hardware related details and provide a more a uniform
> > environment for the kernel start-up.
> > 
> > 
> > Roberto Waltman
> > 
> > 
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> >
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > 
> > 
> > 
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source at linux.davincidsp.com
> >
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > 
> 
> 
> 
> 



More information about the Davinci-linux-open-source mailing list