Decompressing image slow

I have a project that was previously in a BeagleBoard-XM and now for a similar board with the same processor, power management, but with twice the memory and uses a Flash NAND memory.

The boot performs without problems via microSD, however, the decompressing takes about 4s.

QNX6.5
Processor ARM OMAP3730
Memory RAM 512M
NAND FLASH MICRON 2G

PS: I had to use a newer u-boot 2016.01, for the old version 2011.06 crash(hangs) on startup.

Decompression is CPU intensive. Some older bsp’s may leave the ARM i-cache and d-cache disabled after ipl. That means that when startup has to decompress the image, it takes the cpu 7 or 8 times longer than normal. Sounds like that is what is happening in your case.

Right! Makes sense.
I’ll check the “start”.
Soon put the result.

I added the following code at the end of cstart.S

/*
 * Set the translation table base
 */
ldr		r0, =_arm_board_ttb			// set start of Translation Table base
orr		r0, r0, #((3 << 3) | 3)
mcr		p15, 0, r0, c2, c0, 0



/* Enable the MMU, I-Cache and D-Cache */
mrc		p15, 0, r0, c1, c0, 0
BIC		r0, r0, #(1 << 12)			// enable I Cache
BIC		r0, r0, #(1 <<  2)			// enable D Cache
BIC		r0, r0, #(1	<<  0)			// enable MMU
mcr		p15, 0, r0, c1, c0, 0

A code example of TI JACINTO with Cortex-A8 to use the info Caches.

AFTER:
D cache is disabled
I cache is enabled
MMU is disabled
CP15 control register = 0x00c5187c
CP15 control register C bit is enabled
CP15 aux control register = 0x00000042
CP15 aux control register L2EN bit is enabled
L2 is enabled

BEFORE:
D cache is enabled
I cache is enabled
MMU is enabled
CP15 control register = 0x00c5187c
CP15 control register C bit is enabled
CP15 aux control register = 0x00000042
CP15 aux control register L2EN bit is enabled
L2 is enabled

But Decompressing still is slower. I forgot to add some routine?

Link to my cstart.S → pastebin.com/gipwTiQn

Check SD card communication speed. It can be configured at basic rate by default.

The two cards microSD Class 10 and has the same problem, incidentally, booting the NAND also occurs this.

It looks like you put the code in startup. Are you sure it executes BEFORE decompression?

Another thing to check is processor speed, but u-boot should set it at a high rate (unless startup resets processor clock somewhere…)

Yeah, this code in startup is executes before decompression, and before init clocks, interrupts between others.

I decreases the clock of 1GHz to 720MHz to improve stabilization of peripheral and DPLL but with 1GHz had the same problems, but I will confirm again.

I’m not talking about card speed.
I’m talking about processor sdcard controller configuration. By default, sdcard controller is configured for low speed communication (whatever the sdcard class) that is compatible with all sdcards. Then , the speed might be set to a higher rate after discovering the sdcard capabilities.

This same problem I have decompressing the IFS Memory NAND, you think you can be that too?

You should measure the loading of the image and the decompressing times.
The loading time is SD card/NAND FLASH dependent. The configuration of the controller is of importance.
The decompressing time is CPU/RAM dependent. CPU speed, memory cache (instruction and data) and RAM controller configuration are of importance.