Error "Can validate IVT header" when flashing imx8m mini

cancel
Showing results for 
Search instead for 
Did you mean: 

Error "Can validate IVT header" when flashing imx8m mini

Jump to solution
778 Views
Contributor II

Hello NXP Community,

 

I am trying to create the image of Android Q10.0.0_1.0.0 for IMX8M development kit.

I am new to this kind of stuff, but eager to learn.

Flashing the prebuilt image of Q10.0.0_1.0.0 works.

Following the steps mentioned in the Android User Guide, the source code was pulled

and built successfully, but when attempting to flash the iMX8M Mini, a error is thrown:

1:1      1/ 2 [Can find validate IVT header          ] SDP: boot -f "./uuu_imx_a

I have to mention that, during the build, a warning was appearing frequently:

WARNING '/home/mihai-gisca/Projects/1370/sources/Q10.0.0_1.0.0/android_build/vendor/nxp-opensource/uboot-imx/lpddr4_pmu_train_1d_imem.bin' not found, resulting binary is not-functional

Extract from build log:

...
make[1]: Entering directory '/home/mihai-gisca/android_build/vendor/nxp-opensource/imx-mkimage'
Compiling mkimage_imx8
PLAT=imx8mm HDMI=no
Compiling mkimage_imx8
cc -O2 -Wall -std=c99 -static mkimage_imx8.c -o mkimage_imx8 -lz
./../scripts/pad_image.sh bl31.bin
bl31.bin is padded to 37328
./../scripts/pad_image.sh u-boot-nodtb.bin fsl-imx8mm-evk.dtb
u-boot-nodtb.bin + fsl-imx8mm-evk.dtb are padded to 723232
DEK_BLOB_LOAD_ADDR=0x40400000 TEE_LOAD_ADDR=0xfe000000 ATF_LOAD_ADDR=0x00920000 ./mkimage_fit_atf.sh fsl-imx8mm-evk.dtb > u-boot.its
bl31.bin size:
37328
u-boot-nodtb.bin size:
688880
fsl-imx8mm-evk.dtb size:
34352
./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb
Warning (unit_address_vs_reg): Node /images/uboot@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /images/atf@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /configurations/config@1 has a unit name, but no reg property
FIT description: Configuration to load ATF before U-Boot
Created:         Wed Mar 25 15:36:49 2020
 Image 0 (uboot@1)
  Description:  U-Boot (64-bit)
  Created:      Wed Mar 25 15:36:49 2020
  Type:         Standalone Program
  Compression:  uncompressed
  Data Size:    688880 Bytes = 672.73 KiB = 0.66 MiB
  Architecture: AArch64
  Load Address: 0x40200000
  Entry Point:  unavailable
 Image 1 (fdt@1)
  Description:  fsl-imx8mm-evk
  Created:      Wed Mar 25 15:36:49 2020
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    34352 Bytes = 33.55 KiB = 0.03 MiB
  Architecture: Unknown Architecture
 Image 2 (atf@1)
  Description:  ARM Trusted Firmware
  Created:      Wed Mar 25 15:36:49 2020
  Type:         Firmware
  Compression:  uncompressed
  Data Size:    37328 Bytes = 36.45 KiB = 0.04 MiB
  Architecture: AArch64
  OS:           Unknown OS
  Load Address: 0x00920000
 Default Configuration: 'config@1'
 Configuration 0 (config@1)
  Description:  fsl-imx8mm-evk
  Kernel:       unavailable
  Firmware:     uboot@1
  FDT:          fdt@1
  Loadables:    atf@1
./mkimage_imx8 -version v1 -fit -loader u-boot-spl-ddr.bin 0x7E1000 -second_loader u-boot.itb 0x40200000 0x60000 -out flash.bin
Platform: i.MX8M (mScale)
ROM VERSION: v1
Using FIT image
LOADER IMAGE: u-boot-spl-ddr.bin start addr: 0x007e1000
SECOND LOADER IMAGE: u-boot.itb start addr: 0x40200000 offset: 0x00060000
Output:  flash.bin
========= IVT HEADER [HDMI FW] =========
header.tag:   0x0
header.length:   0x0
header.version:  0x0
entry:    0x0
reserved1:   0x0
dcd_ptr:   0x0
boot_data_ptr:   0x0
self:    0x0
csf:    0x0
reserved2:   0x0
boot_data.start:  0x0
boot_data.size:  0x0
boot_data.plugin:  0x0
========= IVT HEADER [PLUGIN] =========
header.tag:   0x0
header.length:   0x0
header.version:  0x0
entry:    0x0
reserved1:   0x0
dcd_ptr:   0x0
boot_data_ptr:   0x0
self:    0x0
csf:    0x0
reserved2:   0x0
boot_data.start:  0x0
boot_data.size:  0x0
boot_data.plugin:  0x0
========= IVT HEADER [LOADER IMAGE] =========
header.tag:   0xd1
header.length:   0x2000
header.version:  0x41
entry:    0x7e1000
reserved1:   0x57c00
dcd_ptr:   0x0
boot_data_ptr:   0x7e0fe0
self:    0x7e0fc0
csf:    0x80cfc0
reserved2:   0x0
boot_data.start:  0x7e0bc0
boot_data.size:  0x2e460
boot_data.plugin:  0x0
========= OFFSET dump =========
Loader IMAGE:
 header_image_off  0x0
 dcd_off   0x0
 image_off   0x40
 csf_off   0x2c000
 spl hab block:  0x7e0fc0 0x0 0x2c000
Second Loader IMAGE:
 sld_header_off  0x57c00
 sld_csf_off   0x58c20
 sld hab block:  0x401fcdc0 0x57c00 0x1020
make[1]: Leaving directory '/home/mihai-gisca/android_build/vendor/nxp-opensource/imx-mkimage'
make[1]: Entering directory '/home/mihai-gisca/android_build/vendor/nxp-opensource/imx-mkimage'
./../scripts/pad_image.sh bl31.bin
./../scripts/pad_image.sh u-boot-nodtb.bin fsl-imx8mm-evk.dtb
TEE_LOAD_ADDR=0xbe000000 ATF_LOAD_ADDR=0x00920000 VERSION=v1 ./print_fit_hab.sh 0x60000 fsl-imx8mm-evk.dtb
0x40200000 0x5AC00 0xA82F0
0x402A82F0 0x102EF0 0x8630
0x920000 0x10B520 0x91D0
make[1]: Leaving directory '/home/mihai-gisca/android_build/vendor/nxp-opensource/imx-mkimage'
...

OS: Ubuntu 18.04.4 LTS x64 as guest OS

 

Appreciate your efforts.

 

Best regards,

Mihai Gîsca

1 Solution
251 Views
Contributor II

Hello everyone!

I must say that I found a strange behavior of the uuu utility in Linux.

This post here guided me into solving my problem.

I. How I got the error

So, as I mentioned in the main post, after successfully building the source code,

"when attempting to flash the iMX8M Mini, a error is thrown:

 

1:1      1/ 2 [Can find validate IVT header          ] SDP: boot -f "./uuu_imx_a..."

I was doing this using the well known command

[assuming we:

- are located in the created android_build/out/target/product/evk_8mm build folder

and

- have the uuu utility here (do not forget to use the command chmod a+x uuu from within this directory before attempting anything)]:

sudo ./uuu ./uuu_imx_android_flash.sh -f imx8mm -e -u trusty -d mipi-panel

II. What is the solution

In the mentioned link is said that (the inspection of the uuu_imx_android_flash.sh confirms this), the .sh file is creating a script in the /tmp folder, named uuu.lst. I executed the command (from within the /tmp; the uuu is the same as mentioned above, just moved to other location, do not forget the same chmod a+x uuu if it is a fresh uuu):

sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Auto-adding USB ports

If you are doing all this from within a virtual machine, you might get an error regarding some USB stuff.

You must pass board-specific USB ports to virtual machine automatically when these ports are detected.

When powering on the board (not just connecting the power supply, but also turning on the power switch), a specific USB port appears in the Devices - USB of the virtual machine window. For me it is called "NXP SemiConductors Inc SE Blank". Click Devices - USB - USB Settings... - USB-plus icon and select "NXP SemiConductors Inc SE Blank".

 

Execute the command again: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Received an error regarding USB stuff. After checking the Devices - USB, I found another port. For me it is called "FSL USB download gadget". Click Devices - USB - USB Settings... - USB-plus icon and select "FSL USB download gadget".

Execute the command again: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Received another error. After checking the Devices - USB, I found another port called the same "FSL USB download gadget". Click Devices - USB - USB Settings... - USB-plus icon and select the second "FSL USB download gadget".

This time, executing the command: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

is successful.

This is my first time working with this kind of stuff and I have no knowledge about how it works.

Best regards,

Mihai Gîsca

P.S. If NXP employees have something to tell about this, error or not, please do reply to this post.
P.P.S. For people interested in and without knowledge of this kind of things, it is really hard to do something meaningful. Please, NXP, do consider making guides for beginners in all aspects of starting from scratch.

P.P.P.S. The bureaucracy of accepting posts and replies is really annoying (just my opinion, no offense :smileyhappy:)

Specs:

Windows 10 as host OS

VirtualBox 6.1.4 (installed on host OS)

VirtualBox Extension pack 6.1.4 (installed on host OS)

Ubuntu 18.04.4 LTS as guest OS (.iso image installed with VirtualBox)

VirtualBox Guest Additions 6.1.2 (6.1.4 was buggy at that moment, link here, installed on guest OS)

View solution in original post

0 Kudos
5 Replies
252 Views
Contributor II

Hello everyone!

I must say that I found a strange behavior of the uuu utility in Linux.

This post here guided me into solving my problem.

I. How I got the error

So, as I mentioned in the main post, after successfully building the source code,

"when attempting to flash the iMX8M Mini, a error is thrown:

 

1:1      1/ 2 [Can find validate IVT header          ] SDP: boot -f "./uuu_imx_a..."

I was doing this using the well known command

[assuming we:

- are located in the created android_build/out/target/product/evk_8mm build folder

and

- have the uuu utility here (do not forget to use the command chmod a+x uuu from within this directory before attempting anything)]:

sudo ./uuu ./uuu_imx_android_flash.sh -f imx8mm -e -u trusty -d mipi-panel

II. What is the solution

In the mentioned link is said that (the inspection of the uuu_imx_android_flash.sh confirms this), the .sh file is creating a script in the /tmp folder, named uuu.lst. I executed the command (from within the /tmp; the uuu is the same as mentioned above, just moved to other location, do not forget the same chmod a+x uuu if it is a fresh uuu):

sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Auto-adding USB ports

If you are doing all this from within a virtual machine, you might get an error regarding some USB stuff.

You must pass board-specific USB ports to virtual machine automatically when these ports are detected.

When powering on the board (not just connecting the power supply, but also turning on the power switch), a specific USB port appears in the Devices - USB of the virtual machine window. For me it is called "NXP SemiConductors Inc SE Blank". Click Devices - USB - USB Settings... - USB-plus icon and select "NXP SemiConductors Inc SE Blank".

 

Execute the command again: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Received an error regarding USB stuff. After checking the Devices - USB, I found another port. For me it is called "FSL USB download gadget". Click Devices - USB - USB Settings... - USB-plus icon and select "FSL USB download gadget".

Execute the command again: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

Received another error. After checking the Devices - USB, I found another port called the same "FSL USB download gadget". Click Devices - USB - USB Settings... - USB-plus icon and select the second "FSL USB download gadget".

This time, executing the command: sudo /home/mihai-gisca/uuu/1.3.134/uuu -v ./uuu.lst

is successful.

This is my first time working with this kind of stuff and I have no knowledge about how it works.

Best regards,

Mihai Gîsca

P.S. If NXP employees have something to tell about this, error or not, please do reply to this post.
P.P.S. For people interested in and without knowledge of this kind of things, it is really hard to do something meaningful. Please, NXP, do consider making guides for beginners in all aspects of starting from scratch.

P.P.P.S. The bureaucracy of accepting posts and replies is really annoying (just my opinion, no offense :smileyhappy:)

Specs:

Windows 10 as host OS

VirtualBox 6.1.4 (installed on host OS)

VirtualBox Extension pack 6.1.4 (installed on host OS)

Ubuntu 18.04.4 LTS as guest OS (.iso image installed with VirtualBox)

VirtualBox Guest Additions 6.1.2 (6.1.4 was buggy at that moment, link here, installed on guest OS)

View solution in original post

0 Kudos
251 Views
NXP TechSupport
NXP TechSupport

Hi Mihai

lpddr4_pmu_train_1d_imem.bin can be found in

https://community.nxp.com/docs/DOC-340179 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

251 Views
Contributor II

Hello Mr. Padykov,

But isn't that lpddr4_pmu_train_1d_imem.bin the same one in

~/android_build/vendor/nxp-source/imx-mkimage/iMX8M ?

There are also the rest of the binary files.

Shouldn't the process of uboot build take those binaries?

If so, why it looks for them in

~/android_build/vendor/nxp-opensource/uboot-imx instead?

Should I copy them from

~/android_build/vendor/nxp-source/imx-mkimage/iMX8M

to

~/android_build/vendor/nxp-opensource/uboot-imx ?

Thank you for your time.

Best regards,

Mihai Gîsca

0 Kudos
251 Views
NXP TechSupport
NXP TechSupport

Hi Mihai

 

yes firmware may be different as described in sect.4.3 Building u-boot image

MSCALE_DDR_Tool_User_Guide.pdf included in

i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 

 

Best regards
igor

0 Kudos
251 Views
Contributor II

Hello, Mr. Padykov

Is it possible that below commands can make a wrong bootloader for imx8m mini board under Q10.0.0_0.0.0?

source build/envsetup.sh

lunch evk_8mm-usedebug

./imx-make.sh bootloader kernel -j4 2>&1 | tee build-log.txt

Thank you for your support!

Best regards,

Mihai Gîsca

P.S. Please, if possible, provide a step by step guide for beginners.

0 Kudos