[U-Boot-Users] Uncompression of image takes time.

[U-Boot-Users] Uncompression of image takes time.

[Adarsh Babu]

Hi,

I have an image which is 1.5MB in size after compression, thats is done for 
MCF5271. When i try to load this on a MCF5271 eval board using u-boot 1.2.0 it 
takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with U-
Boot 1.2.0 and then tried to start the same image(which was done for MCF5271). 
It was very fast. The checksum verification finish off in a second and 
uncompression in 10 seconds ! 

The clock configurations for both are provided below:
M5272C3.h
define CFG_HZ			1000
#define CFG_CLK			66000000

M5271EVB.h:
define CFG_HZ			1000000
#define CFG_CLK			100000000

What should I do to get the image to uncompress faster in the MCF5271 EVB?

Regards,
Adarsh.
 

[U-Boot-Users] Uncompression of image takes time.

[Jerry Van Baren]

Adarsh Babu wrote:
> Hi,
> 
> I have an image which is 1.5MB in size after compression, thats is done for 
> MCF5271. When i try to load this on a MCF5271 eval board using u-boot 1.2.0 it 
> takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with U-
> Boot 1.2.0 and then tried to start the same image(which was done for MCF5271). 
> It was very fast. The checksum verification finish off in a second and 
> uncompression in 10 seconds ! 
> 
> The clock configurations for both are provided below:
> M5272C3.h
> define CFG_HZ			1000
> #define CFG_CLK			66000000
> 
> M5271EVB.h:
> define CFG_HZ			1000000
> #define CFG_CLK			100000000
> 
> What should I do to get the image to uncompress faster in the MCF5271 EVB?
> 
> Regards,
> Adarsh.

1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
tick interrupt should be running 1000 times per second to match.  If you 
are indeed ticking 1,000,000 times per second, you are spending all of 
your processor time in your timer ISR.

2) Why is your image 1.5MB?  I suspect you have large unused areas of 
memory (typically due to ISR vectors, followed by a huge unused gap, 
followed by the code).  If you fix your image size (assuming it is 
broken), the checksum and uncompress will be much faster.

gvb

[U-Boot-Users] Uncompression of image takes time.

[Adarsh Babu]

Jerry Van Baren <gerald.vanbaren <at> smiths-aerospace.com> writes:

> 
> Adarsh Babu wrote:
> > Hi,
> > 
> > I have an image which is 1.5MB in size after compression, thats is done 
for 
> > MCF5271. When i try to load this on a MCF5271 eval board using u-boot 
1.2.0 it 
> > takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with 
U-
> > Boot 1.2.0 and then tried to start the same image(which was done for 
MCF5271). 
> > It was very fast. The checksum verification finish off in a second and 
> > uncompression in 10 seconds ! 
> > 
> > The clock configurations for both are provided below:
> > M5272C3.h
> > define CFG_HZ			1000
> > #define CFG_CLK			66000000
> > 
> > M5271EVB.h:
> > define CFG_HZ			1000000
> > #define CFG_CLK			100000000
> > 
> > What should I do to get the image to uncompress faster in the MCF5271 EVB?
> > 
> > Regards,
> > Adarsh.
> 
> 1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
> tick interrupt should be running 1000 times per second to match.  If you 
> are indeed ticking 1,000,000 times per second, you are spending all of 
> your processor time in your timer ISR.
> 
> 2) Why is your image 1.5MB?  I suspect you have large unused areas of 
> memory (typically due to ISR vectors, followed by a huge unused gap, 
> followed by the code).  If you fix your image size (assuming it is 
> broken), the checksum and uncompress will be much faster.
> 
> gvb
> 

Hi Jerry,

I tried the same after modifying the CFG_HZ to 1000. But i still get the same 
result. Its as if there is no effect. The image size is 1.5MB becos its just 
not a kernel image. Its kernel + our application. Could this be a problem with 
the timer initialization and cofiguration?

Regards,
Adarsh.

[U-Boot-Users] Uncompression of image takes time.

[Adarsh Babu]

Adarsh Babu <adarshrbpin <at> yahoo.co.in> writes:

> 
> Jerry Van Baren <gerald.vanbaren <at> smiths-aerospace.com> writes:
> 
> > 
> > Adarsh Babu wrote:
> > > Hi,
> > > 
> > > I have an image which is 1.5MB in size after compression, thats is done 
> for 
> > > MCF5271. When i try to load this on a MCF5271 eval board using u-boot 
> 1.2.0 it 
> > > takes about 25 secs to just uncompress. I loaded a MCF5272 eval board 
with 
> U-
> > > Boot 1.2.0 and then tried to start the same image(which was done for 
> MCF5271). 
> > > It was very fast. The checksum verification finish off in a second and 
> > > uncompression in 10 seconds ! 
> > > 
> > > The clock configurations for both are provided below:
> > > M5272C3.h
> > > define CFG_HZ			1000
> > > #define CFG_CLK			66000000
> > > 
> > > M5271EVB.h:
> > > define CFG_HZ			1000000
> > > #define CFG_CLK			100000000
> > > 
> > > What should I do to get the image to uncompress faster in the MCF5271 
EVB?
> > > 
> > > Regards,
> > > Adarsh.
> > 
> > 1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
> > tick interrupt should be running 1000 times per second to match.  If you 
> > are indeed ticking 1,000,000 times per second, you are spending all of 
> > your processor time in your timer ISR.
> > 
> > 2) Why is your image 1.5MB?  I suspect you have large unused areas of 
> > memory (typically due to ISR vectors, followed by a huge unused gap, 
> > followed by the code).  If you fix your image size (assuming it is 
> > broken), the checksum and uncompress will be much faster.
> > 
> > gvb
> > 
> 
> Hi Jerry,
> 
> I tried the same after modifying the CFG_HZ to 1000. But i still get the 
same 
> result. Its as if there is no effect. The image size is 1.5MB becos its just 
> not a kernel image. Its kernel + our application. Could this be a problem 
with 
> the timer initialization and cofiguration?
> 
> Regards,
> Adarsh.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
Hi Jerry,

The MCF5271EVB.h found in u-boot-1.2.0 is something like this.
#ifndef _M5271EVB_H
#define _M5271EVB_H

#define DEBUG
#undef DEBUG

/*
 * High Level Configuration Options (easy to change)
 */
#define CONFIG_MCF52x2		/* define processor family */
#define CONFIG_M5271		/* define processor type */
#define CONFIG_M5271EVB		/* define board type */

#define CONFIG_IPADDR		192.168.30.1
#define CONFIG_SERVERIP		192.168.1.1
#define CONFIG_ETHADDR		00:06:3b:01:41:55

#define CONFIG_BAUDRATE		19200
#define CFG_BAUDRATE_TABLE	{ 9600 , 19200 , 38400 , 57600, 115200 }

#undef CONFIG_WATCHDOG		/* disable watchdog */

#define CONFIG_BOOTDELAY	5

/* Configuration for environment
 * Environment is embedded in u-boot in the second sector of the flash
 */
#ifndef CONFIG_MONITOR_IS_IN_RAM
#define CFG_ENV_OFFSET		0x4000
#define CFG_ENV_SECT_SIZE	0x2000
#define CFG_ENV_IS_IN_FLASH	1
#else
#define CFG_ENV_ADDR		0xffe04000
#define CFG_ENV_SECT_SIZE	0x2000
#define CFG_ENV_IS_IN_FLASH	1
#endif

#define CONFIG_COMMANDS	 ((CONFIG_CMD_DFL | CFG_CMD_PING | CFG_CMD_NET ) & ~
(CFG_CMD_LOADS | CFG_CMD_LOADB))

/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */
#include <cmd_confdefs.h>

#define CFG_PROMPT		"=> "
#define CFG_LONGHELP				/* undef to save memory	
	*/

#if (CONFIG_COMMANDS & CFG_CMD_KGDB)
#define CFG_CBSIZE		1024		/* Console I/O Buffer Size
	*/
#else
#define CFG_CBSIZE		256		/* Console I/O Buffer Size
	*/
#endif
#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
#define CFG_MAXARGS		16		/* max number of command args
	*/
#define CFG_BARGSIZE		CFG_CBSIZE	/* Boot Argument Buffer Size
	*/

#define CFG_LOAD_ADDR		0x00100000

#define CFG_MEMTEST_START	0x400
#define CFG_MEMTEST_END		0x380000

#define CFG_HZ			1000
#define CFG_CLK			100000000

/*
 * Low Level Configuration Settings
 * (address mappings, register initial values, etc.)
 * You should know what you are doing if you make changes here.
 */

#define CFG_MBAR		0x40000000	/* Register Base Addrs */

/* Enable FEC ethernet */
#define FEC_ENET
#define CONFIG_NET_RETRY_COUNT	5
#define CFG_ENET_BD_BASE	0x480000

/*
 * Definitions for initial stack pointer and data area (in DPRAM)
 */
#define CFG_INIT_RAM_ADDR	0x20000000
#define CFG_INIT_RAM_END	0x1000	/* End of used area in internal SRAM
	*/
#define CFG_GBL_DATA_SIZE	64	/* size in bytes reserved for initial 
data */
#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
#define CFG_INIT_SP_OFFSET	CFG_GBL_DATA_OFFSET

/*
 * Start addresses for the final memory configuration
 * (Set up by the startup code)
 * Please note that CFG_SDRAM_BASE _must_ start at 0
 */
#define CFG_SDRAM_BASE		0x00000000
#define CFG_SDRAM_SIZE		16		/* SDRAM size in MB */
#define CFG_FLASH_BASE		0xffe00000

#ifdef	CONFIG_MONITOR_IS_IN_RAM
#define CFG_MONITOR_BASE	0x20000
#else
#define CFG_MONITOR_BASE	(CFG_FLASH_BASE + 0x400)
#endif

#define CFG_MONITOR_LEN		0x40000
#define CFG_MALLOC_LEN		(256 << 10)
#define CFG_BOOTPARAMS_LEN	(64*1024)

/*
 * For booting Linux, the board info and command line data
 * have to be in the first 8 MB of memory, since this is
 * the maximum mapped by the Linux kernel during initialization ??
 */
#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for 
Linux */

/* FLASH organization */
#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	
	*/
#define CFG_MAX_FLASH_SECT	11	/* max number of sectors on one chip
	*/
#define CFG_FLASH_ERASE_TOUT	1000

#define CFG_FLASH_CFI		1
#define CFG_FLASH_CFI_DRIVER	1
#define CFG_FLASH_SIZE		0x200000

/* Cache Configuration */
#define CFG_CACHELINE_SIZE	16

/* Port configuration */
#define CFG_FECI2C		0xF0

#endif	/* _M5271EVB_H */

Does anything look odd or our of place in here that might cause the Image 
decompression to be close to 25 seconds??

Reagards,
Adarsh.

[U-Boot-Users] Uncompression of image takes time.

[Jerry Van Baren]

Adarsh Babu wrote:
> Jerry Van Baren <gerald.vanbaren <at> smiths-aerospace.com> writes:
> 
>> Adarsh Babu wrote:
>>> Hi,
>>>
>>> I have an image which is 1.5MB in size after compression, thats is done 
> for 
>>> MCF5271. When i try to load this on a MCF5271 eval board using u-boot 
> 1.2.0 it 
>>> takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with 
> U-
>>> Boot 1.2.0 and then tried to start the same image(which was done for 
> MCF5271). 
>>> It was very fast. The checksum verification finish off in a second and 
>>> uncompression in 10 seconds ! 
>>>
>>> The clock configurations for both are provided below:
>>> M5272C3.h
>>> define CFG_HZ			1000
>>> #define CFG_CLK			66000000
>>>
>>> M5271EVB.h:
>>> define CFG_HZ			1000000
>>> #define CFG_CLK			100000000
>>>
>>> What should I do to get the image to uncompress faster in the MCF5271 EVB?
>>>
>>> Regards,
>>> Adarsh.
>> 1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
>> tick interrupt should be running 1000 times per second to match.  If you 
>> are indeed ticking 1,000,000 times per second, you are spending all of 
>> your processor time in your timer ISR.
>>
>> 2) Why is your image 1.5MB?  I suspect you have large unused areas of 
>> memory (typically due to ISR vectors, followed by a huge unused gap, 
>> followed by the code).  If you fix your image size (assuming it is 
>> broken), the checksum and uncompress will be much faster.
>>
>> gvb
>>
> 
> Hi Jerry,
> 
> I tried the same after modifying the CFG_HZ to 1000. But i still get the same 
> result. Its as if there is no effect. The image size is 1.5MB becos its just 
> not a kernel image. Its kernel + our application. Could this be a problem with 
> the timer initialization and cofiguration?
> 
> Regards,
> Adarsh.

Hi Adarsh,

I don't have any M527x experience, so I cannot say anything with detail. 
  Just changing CFG_HZ quite likely is not sufficient - usually you need 
to configure the timers in your hardware initialization routines and 
CFG_HZ simply reflects the choices you (or someone) made at 
initialization time.

If this is the case, and if you timer is really ticking at 1/100 your 
master clock rate, that would cause serious slowing of execution.  You 
will have to chase down what CFG_HZ is used for and how your hardware 
timer is initialized.  I simply don't have the knowledge or information.

HTH,
gvb

[U-Boot-Users] Uncompression of image takes time.

[Adarsh Babu]

Jerry Van Baren <gerald.vanbaren <at> comcast.net> writes:
> 
> Hi Adarsh,
> 
> Other generic things that can cause slow execution are:
> * Caches disabled (data and/or instruction)
>    * Caches are very sharp knives: they can slice and
>        dice quickly and finely, or they can turn on
>        you and slice your fingers off.  For initial board
>        bring-up, caches are usually disabled.
> * Memory configuration
>    * The memory interface is typically initialized with
>        the slowest settings possible on power up: if they
>        are not optimized, the CPU will run slower than it
>        could run.
> 
> Let us know what you find, so the next person down this path will find 
> the solution  rather than just the problem.  (The internet: the worlds 
> largest knowledge base hidden in a vast wasteland of ignorance.)
> 
> HTH,
> gvb
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
Hi Jerry,

I enabled the Instruction cache for MCF5271 and then tried decompressing the 
image. I have got the decompression time down to 12 seconds from the earlier 
25 seconds with this implementation. Thanx a lot for the suggestion.

Regards,
Adarsh.

[U-Boot-Users] Uncompression of image takes time.

[Jerry Van Baren]

> Adarsh Babu wrote:
>> Jerry Van Baren <gerald.vanbaren <at> smiths-aerospace.com> writes:
>> 
>>> Adarsh Babu wrote:
>>>> Hi,
>>>>
>>>> I have an image which is 1.5MB in size after compression, thats is done 
>> for 
>>>> MCF5271. When i try to load this on a MCF5271 eval board using u-boot 
>> 1.2.0 it 
>>>> takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with 
>> U-
>>>> Boot 1.2.0 and then tried to start the same image(which was done for 
>> MCF5271). 
>>>> It was very fast. The checksum verification finish off in a second and 
>>>> uncompression in 10 seconds ! 
>>>>
>>>> The clock configurations for both are provided below:
>>>> M5272C3.h
>>>> define CFG_HZ			1000
>>>> #define CFG_CLK			66000000
>>>>
>>>> M5271EVB.h:
>>>> define CFG_HZ			1000000
>>>> #define CFG_CLK			100000000
>>>>
>>>> What should I do to get the image to uncompress faster in the MCF5271 EVB?
>>>>
>>>> Regards,
>>>> Adarsh.
>>> 1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
>>> tick interrupt should be running 1000 times per second to match.  If you 
>>> are indeed ticking 1,000,000 times per second, you are spending all of 
>>> your processor time in your timer ISR.
>>>
>>> 2) Why is your image 1.5MB?  I suspect you have large unused areas of 
>>> memory (typically due to ISR vectors, followed by a huge unused gap, 
>>> followed by the code).  If you fix your image size (assuming it is 
>>> broken), the checksum and uncompress will be much faster.
>>>
>>> gvb
>>>
>> 
>> Hi Jerry,
>> 
>> I tried the same after modifying the CFG_HZ to 1000. But i still get the same 
>> result. Its as if there is no effect. The image size is 1.5MB becos its just 
>> not a kernel image. Its kernel + our application. Could this be a problem with 
>> the timer initialization and cofiguration?
>> 
>> Regards,
>> Adarsh.
> 
> Hi Adarsh,
> 
> I don't have any M527x experience, so I cannot say anything with detail. 
>   Just changing CFG_HZ quite likely is not sufficient - usually you need 
> to configure the timers in your hardware initialization routines and 
> CFG_HZ simply reflects the choices you (or someone) made at 
> initialization time.
> 
> If this is the case, and if you timer is really ticking at 1/100 your 
> master clock rate, that would cause serious slowing of execution.  You 
> will have to chase down what CFG_HZ is used for and how your hardware 
> timer is initialized.  I simply don't have the knowledge or information.
> 
> HTH,
> gvb

Hi Adarsh,

Other generic things that can cause slow execution are:
* Caches disabled (data and/or instruction)
   * Caches are very sharp knives: they can slice and
       dice quickly and finely, or they can turn on
       you and slice your fingers off.  For initial board
       bring-up, caches are usually disabled.
* Memory configuration
   * The memory interface is typically initialized with
       the slowest settings possible on power up: if they
       are not optimized, the CPU will run slower than it
       could run.

Let us know what you find, so the next person down this path will find 
the solution  rather than just the problem.  (The internet: the worlds 
largest knowledge base hidden in a vast wasteland of ignorance.)

HTH,
gvb