Hello Adam/Peter,

-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Adam Ford Sent: Tuesday, December 8, 2020 2:48 PM To: Peter Bergin peter@berginkonsult.se Cc: U-Boot Mailing List u-boot@lists.denx.de; NXP Linux Team <linux- imx@nxp.com> Subject: Re: Boot problems imx8mp_evk

This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email.

On Wed, Sep 30, 2020 at 6:06 AM Peter Bergin peter@berginkonsult.se wrote:

...

Hi,

I'm following the README to bring up u-boot on a imx8mp EVK board. My boot ends up in this on the console:

 U-Boot SPL 2020.10-rc5-00049-gd44d46e9fa (Sep 30 2020 - 11:46:20 +0200)
 Normal Boot
 WDT:   Started with servicing (60s timeout)
 Trying to boot from BOOTROM
 image offset 0x8000, pagesize 0x200, ivt offset 0x0
 Can't support legacy image
 SPL: failed to boot from all boot devices
 ### ERROR ### Please RESET the board ###

Any ideas what is going wrong? How to debug further?

I am trying to port U-Boot to an i.MX8M Nano and I am getting the same result.

This might not be related, but looking at the ATF branch [imx_5.4.3_2.0.0] - it appears to be too old, at least for i.MX8M Plus. I was able to run the U-Boot 2020.10 with ATF built from [imx_5.4.47_2.2.0] on the i.MX8M Plus and it does boot successful.

Boot log show the following banner when BOOTROM finishes up the copy: NOTICE: BL31: v2.2(release):rel_imx_5.4.47_2.2.0-0-gc949a888e-dirty NOTICE: BL31: Built : 05:51:50, Sep 9 2020

Peter, i.MX8M Plus support in NXP ATF fork appears to be added by commit https://source.codeaurora.org/external/imx/imx-atf/commit/?id=6b8249ff58cc88..., and that came in ATF revision far newer than indicated in doc/board/freescale/imx8mp_evk.rst

Try to rebase your ATF to [c949a888e909811db191500c51456391dff61284] and build according to the board doc file.

...

Thanks, /Peter

-- Andrey

Hello Peter,

-----Original Message----- From: Peter Bergin peter@berginkonsult.se Sent: Friday, February 12, 2021 9:01 AM To: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Adam Ford aford173@gmail.com Cc: U-Boot Mailing List u-boot@lists.denx.de; NXP Linux Team <linux- imx@nxp.com> Subject: Re: Boot problems imx8mp_evk

Hi,

this has been put aside for a while but tested this again and problem still remains for me.

...

...

...

Hi,

I'm following the README to bring up u-boot on a imx8mp EVK board. My boot ends up in this on the console:

  U-Boot SPL 2020.10-rc5-00049-gd44d46e9fa (Sep 30 2020 - 11:46:20 +0200)
  Normal Boot
  WDT:   Started with servicing (60s timeout)
  Trying to boot from BOOTROM
  image offset 0x8000, pagesize 0x200, ivt offset 0x0
  Can't support legacy image
  SPL: failed to boot from all boot devices
  ### ERROR ### Please RESET the board ###

Any ideas what is going wrong? How to debug further?

I am trying to port U-Boot to an i.MX8M Nano and I am getting the same

result.

...

This might not be related, but looking at the ATF branch [imx_5.4.3_2.0.0] - it

appears to be too old, at least for i.MX8M Plus. I was able to run the U-Boot 2020.10 with ATF built from [imx_5.4.47_2.2.0] on the i.MX8M Plus and it does boot successful.

...

Boot log show the following banner when BOOTROM finishes up the copy: NOTICE: BL31: v2.2(release):rel_imx_5.4.47_2.2.0-0-gc949a888e-dirty NOTICE: BL31: Built : 05:51:50, Sep 9 2020

Peter, i.MX8M Plus support in NXP ATF fork appears to be added by commit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour ce.codeaurora.org%2Fexternal%2Fimx%2Fimx-

atf%2Fcommit%2F%3Fid%3D6b8249

...

ff58cc8853396498a074535dcd7f81beaf&amp;data=04%7C01%7C%7C719a95122be 04

...

757a8b208d8cf2c3dff%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637 48

...

7136220734827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj oiV2lu

...

MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tGc0fgRB0LmDF9 WPNU

...

EMMzjVidBLyf3exwHHN1W15Pk%3D&amp;reserved=0, and that came in ATF revision far newer than indicated in doc/board/freescale/imx8mp_evk.rst

Try to rebase your ATF to [c949a888e909811db191500c51456391dff61284] and

build according to the board doc file.

...

Andrey, Thanks for advice about the commit in imx-atf. Unfortunately it does not seem to solve the issue.

This is what I tested today and where I ended up today:

 $ cd imx-atf
 $ git checkout imx_5.4.70_2.3.0
 $ make PLAT=imx8mp bl31
 $ cd ../u-boot
 $ git checkout master (80c7e4cf76d204d4b726b0cc57a557a9d9c1c453)
 $ cp ../imx-atf/build/imx8mp/release/bl31.bin .
 $ cp

../firmware-imx- 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin lpddr4_pmu_train_1d_dmem.bin $ cp ../firmware-imx- 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin lpddr4_pmu_train_1d_imem.bin $ cp ../firmware-imx- 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin lpddr4_pmu_train_2d_dmem.bin $ cp ../firmware-imx- 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin lpddr4_pmu_train_2d_imem.bin $ export ATF_LOAD_ADDR=0x960000

In the latest ATF, the LOAD_ADDR has been changed from 0x960000 to 0x970000. This was done by commit 48733cb4e ("MLK-24913: plat: imx8mp: change the bl31 physical load address").

 $ make imx8mp_evk_defconfig
 $ make flash.bin
 $ sudo dd if=flash.bin of=/dev/mmcblk0 bs=1024 seek=32

I have the following build script file, which works for me: =============== #!/usr/bin/env bash

set -o xtrace # print commands and their arguments as they are executed set -o errexit # exit immediately if a command exits with a non-zero status

build_dir="/development/imx-boot/build/nxp/imx8mpevk"

rm -rf $build_dir make O=$build_dir imx8mp_evk_defconfig

# Copy auxilary needed files cp ../imx-atf/build/imx8mp/release/bl31.bin "$build_dir/" cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin "$build_dir/lpddr4_pmu_train_1d_dmem.bin" cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin "$build_dir/lpddr4_pmu_train_1d_imem.bin" cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin "$build_dir/lpddr4_pmu_train_2d_dmem.bin" cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin "$build_dir/lpddr4_pmu_train_2d_imem.bin"

make O=$build_dir flash.bin ATF_LOAD_ADDR=0x970000 -j 16 dd if=$build_dir/flash.bin of=$build_dir/sdcard.img bs=1024 seek=32 conv=notrunc ===============

When booting on a imx8mp EVK from NXP the console shows me this:

 U-Boot SPL 2020.04-00033-g633977d904 (Feb 12 2021 - 08:12:50 +0100)

I guess you're using NXP fork of the U-Boot, and not the mainline one. Commit 633977d904 Is not present in the mainline tree, and additional DDR output gives a hint that you're trying to build NXP fork of U-Boot.

Please try the same procedure on the vanilla [master] branch, I was referring to it in my previous mail - no the NXP fork.

Once you'd opt-in for vanilla U-Boot, you can follow the information and steps further in this mail. I never tried to perform those build steps on NXP fork, so I cannot guarantee that all written below would work for it. For vanilla U-Boot it work for me.

 DDRINFO: start DRAM init
 DDRINFO: DRAM rate 4000MTS
 DDRINFO:ddrphy calibration done
 DDRINFO: ddrmix config done
 Normal Boot
 Trying to boot from BOOTROM
 image offset 0x8000, pagesize 0x200, ivt offset 0x0
 Can't support legacy image

IIRC, this indicates that there IVT header contains v1, while imx8mp requires IVT v2 in order to boot using ROMAPI. IVT v1 header only applies to

Can you compare the content of your "$build_dir/flash.log" to this one, it is working for me: --------------------- parsing spl/u-boot-spl.cfgout ========= 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 [LOADER IMAGE] ========= header.tag: 0xd1 header.length: 0x2000 header.version: 0x41 entry: 0x920000 reserved1: 0x0 dcd_ptr: 0x0 boot_data_ptr: 0x91ffe0 self: 0x91ffc0 csf: 0x94bbc0 reserved2: 0x0 boot_data.start: 0x91ffc0 boot_data.size: 0x2dc00 boot_data.plugin: 0x0 ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 image_off 0x40 csf_off 0x2bc00 spl hab block: 0x91ffc0 0x0 0x2bc00

Second Loader IMAGE: sld_header_off 0x58000 sld_csf_off 0x59020 sld hab block: 0x401fcdc0 0x58000 0x1020 ---------------------

 SPL: failed to boot from all boot devices
 ### ERROR ### Please RESET the board ###

The code that fails is in arch/arm/mach-imx/spl_imx_romapi.c

 if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
     image_get_magic(header) == FDT_MAGIC) {
 ....
 } else {
     /* TODO */
     puts("Can't support legacy image\n");
     return -1;
 }

I have traced out 'image_get_magic(header)' on the console and it is a new random value at each power on. I can also note that I have tested branch imx_v2020.04_5.4.70_2.3.0 from from uboot-imx ending up in the same result on the console.

NXP fork of U-Boot does use rather imx-mkimage tool to produce a boot container, I'm not entirely sure that the approach you're trying to execute would work for it.

Anyone that have ideas here how to proceed and where the problem can be? Anyone with a imx8mp EVK on the desk that succeed with building and deploying u-boot on a SD card and can share the workflow?

Yes, I've actually booted imx8mp-evk with latest U-Boot from [master] successfully. Please switch to vanilla U-Boot version and try it out.

Best regards, /Peter

Link: [1]: https://source.codeaurora.org/external/imx/imx-atf/commit/?h=imx_5.4.70_2.3....

-- andrey