Boot problems imx8mp_evk
ZHIZHIKIN Andrey
andrey.zhizhikin at leica-geosystems.com
Fri Feb 12 09:22:07 CET 2021
Hello Peter,
> -----Original Message-----
> From: Peter Bergin <peter at berginkonsult.se>
> Sent: Friday, February 12, 2021 9:01 AM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>; Adam Ford
> <aford173 at gmail.com>
> Cc: U-Boot Mailing List <u-boot at lists.denx.de>; NXP Linux Team <linux-
> imx at 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&data=04%7C01%7C%7C719a95122be
> 04
> >
> 757a8b208d8cf2c3dff%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637
> 48
> >
> 7136220734827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2lu
> >
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGc0fgRB0LmDF9
> WPNU
> > EMMzjVidBLyf3exwHHN1W15Pk%3D&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.0&id=48733cb4e773a7584ced601de9d717efa3d73815
-- andrey
More information about the U-Boot
mailing list