BOOT Colibri iMX6S 256MB IT 1.1B

I have two identical Colibri iMX6S 256MB IT 1.1B cpu.
They behave differently when switched on.
On the first cpu Colibri iMX6S 256MB IT 1.1B Serial: 10942073
In the boot phase we have:
System ready!
Preparing for download …
Loading uncompressed image …
Reading image size from sector 303105
Loading 39921268 bytes to RAM
… …
Done.
Launching image at 10200000.

On the second cpu Colibri iMX6S 256MB IT 1.1B Serial: 10960976
In the boot phase we have:
System ready!
Preparing for download …
Loading uncompressed image …
Reading image size from sector 303105
… …
Done.
Launching image at 10200000.

The first has a much faster boot than the second.
How come?

Regards.
Sergio Masin

Could you please specify WInCE version and a BSP version ?
Please also enable serial debug output. Then collect and share logs for both cases.

Hello Alex.

WinCE 8.00 (Build 6247).

BSP imx6_wince8bsp_1.6-20191223.

BOOT1.TXT: serial output debug of som booting slow.

BOOT2_RAM.TXT: serial output debug of som booting quick.

On both of them I am using the same image ce.

Regards.

Sergio Masin.

BOOT1.txt (112 KB)

BOOT2_RAM.TXT (112 KB)

Unfortunately neither one attached file have enabled debug serial output.
Please :

  1. Enter the Bootloader Menu
  2. In the bootloader, type:

X
set dbg.serial = 1 // 0: disable, 1: enable
save dbg
Then collect bootlogs.
Please also upgrade WInCE BSP to 1.8 version iMX6 WEC Software

Hello Alex.

Attached you will find the required files.

In BOOTLOGS2.TXT is displayed:

Loading 39921268 bytes to RAM

It is not in BOOTLOGS1.TXT.

The progression of dot points is much faster in boot2.txt than in boot1.txt.

It is not possible to make sure that also the som relative to BOOTLOGS1.txt has:

Loading 39921268 bytes to RAM

In order to have a faster boot?

Regards.

Sergio Masin.

BOOTLOGS1.txt (2.77 KB)

BOOTLOGS2.txt (2.75 KB)

Could you provide some data about boot time ? How long does it take to boot for each module?
Please also upgrade WInCE BSP to 1.8 version iMX6 WEC Software

Hello Alex.

The boot it displays (BOOTLOGS2.TXT):

System ready!

Preparing for download …

Loading uncompressed image …

Reading image size from sector 303105

Loading 39921268 bytes to RAM

… …

Done.

Launching image at 10200000.

The progression of the points lasts 5 seconds.

The boot it displays (BOOTLOGS1.TXT):

System ready!

Preparing for download …

Loading uncompressed image …

Reading image size from sector 303105

… …

Done.

Launching image at 10200000.

The progression of the points lasts 13 seconds.

What I want to understand is why on a som it displays:

Loading 39921268 bytes to RAM

while on the other no?

Upgrading to the BSP 1.8 version is a hard job, because we already had several problems with the BSP 1.7 version of slow network communication between the various devices and of renaming FlashDisk folders with FlashDisk2, so we had to go back to version 1.6.

Regards.

Sergio

The “FlashDIsk2” issue related to asynchronous driver loading. Please see description here.

Could you check if your modules have the same eMMC chip or not?
Version 1.8 has fix for occasional Filesystem corruption problem when using Trim feature
Otherwise you should disable Trim.

[HKEY_LOCAL_MACHINE\Drivers\SDCARD\ClientDrivers\Class\MMC_Class\High_Capacity] EnableTrim=dword:0

Hello Alex.

Where do I find the description of the eMMC chip?

But how come two identical som that mount the same image CE 8.0 behave differently when switched on.

Because a som at boot displays:

Loading 39921268 bytes to RAM

and the other not?

Regards.

Sergio.

There are two ways to find this:

It may happened if eMMC chips has different block size. Please chek boot loader code snippet below

	dwActualLength = *(DWORD*)(pSectorBuf +  flashInfo.dwBytesPerBlock - 4);
	pLengthMagic = (CHAR*)(pSectorBuf +  flashInfo.dwBytesPerBlock - 4 - IMAGE_LENGTH_MAGIC_SIZE);

	if ((memcmp(pLengthMagic, IMAGE_LENGTH_MAGIC_STRING, IMAGE_LENGTH_MAGIC_SIZE) == 0) && 
		(dwActualLength!= 0 &&  dwActualLength <= SDImageCfg.dwNkSize))
	{
    
		OALMSG(1, (_T("Loading %d bytes to RAM\r\n"), dwActualLength));
    
		if (dwActualLength % flashInfo.dwBytesPerBlock)
			endSectorAddr = startSectorAddr + (dwActualLength / flashInfo.dwBytesPerBlock) + 1;  
		else
			endSectorAddr = startSectorAddr + (dwActualLength / flashInfo.dwBytesPerBlock);
	}

Hello Alex.

Both SOMs have the same eMMC chip:

MC

B220100

MX52LM04A11

XUI

8H792904

Regards.

Sergio M.

Looks lokes you are using a custom build on the “fast” module bootloader read image length from image header and loads only requiered amount of data from eMMC to RAM on the “slow” module header is corrupted and bootloader uses fallback method which requires to search for end of image . Could you please flash a Toradex provided image preferably v1.8 (but you can use 1.6t if you wish) using the same way to both modules?

Hi @smasin ,

If you write your custom uncompressed image with the Updated Tool it will boot faster then if you write it with Toradex Easy Installer. The reason is that The Update Tool adds the correct image size at sector 303105. If this information is not found the maximum of 100MB are loaded so it takes longer.

Hello Germano.

I used “Update Tool” for write same image for both som.

Regards.

Sergio M.

Hi @smasin ,

It’s really strange… Did you use the same UpdateTool version on both modules?
What version of the UpdateTool did you use, what Image Version was it running on?

Can you try to do this 2 things:

  1. make a Backup of the Image on “long boot time module” using the update tool and send it to us.
  2. Re-do the Update on the “long boot time module” to see if it changes the behavior.

Hello Germano.

I restored with the 1.6 CE 8.0 image downloaded from Toradex, then I reloaded my image and the problem was solved.

Thank you.

Regards.

Sergio M.