i.MXMN: USB Serial Boot on Custom Board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MXMN: USB Serial Boot on Custom Board

Jump to solution
1,978 Views
wkz
Contributor I

I working on bringing up a new i.MX8MN-based board, booting using the serial download mode. U-Boot is built from the head of `imx_v2020.04_5.4.24_2.1.0` with the addition of our board, which at the moment is basically a copy of the EVK except for our board using LPDDR4.

Working so far:

- UUU manages to connect to the BOOTROM and downloads the SPL.
- SPL runs, and correctly sets up LPDDR4 (verified from JTAG).
- SPL starts to download the U-Boot ITB and finds the expected header.

This is where the show stops. The SPL calls into the BOOTROM to request more image data, but control is never returned to SPL. Attaching a debugger shows the CPU stuck in the BOOTROM somewhere.

This is the output on the console:

DDRINFO: start DRAM init
DDRINFO: DRAM rate 3200MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
Find FIT header 0x&4803ae00, size 938
Need continue download 1024

 

On the host side, UUU initially shows a progress bar counting up to about 33%, then exits with the following output:

uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.4.43-4-g9aff92a

Success 0 Failure 1


1:71 1/ 1 [HID(W):LIBUSB_ERROR_TIMEOUT ] SDPS: boot -f output/images/flash.bin

Error: HID(W):LIBUSB_ERROR_TIMEOUT

Any help is greatly appreciated!

0 Kudos
1 Solution
1,954 Views
wkz
Contributor I

I figured out what the problem was. I incorrectly assumed that the normal `make $(BOARD)_defconfig && make` was enough. I then discovered that for i.MX8MN you also need to set the variable `ATF_LOAD_ADDR`. If this is not done it will default to an address in SRAM where the SPL is already executing. The SPL will then try to memcpy the ATF over itself.

Needless to say that failed spectacularly.

View solution in original post

0 Kudos
2 Replies
1,955 Views
wkz
Contributor I

I figured out what the problem was. I incorrectly assumed that the normal `make $(BOARD)_defconfig && make` was enough. I then discovered that for i.MX8MN you also need to set the variable `ATF_LOAD_ADDR`. If this is not done it will default to an address in SRAM where the SPL is already executing. The SPL will then try to memcpy the ATF over itself.

Needless to say that failed spectacularly.

0 Kudos
1,958 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Hi, wkz,

   Below is my advice for you:

1. Using uuu tool to program u-boot to eMMC or SD

if you are using windows, windows 10 is recommended. on windows command line:

> uuu -b emmc imx-boot-imx8mn-flash-evk.bin ( assume this is the bootloader's name, and program it into eMMC)

or

> uuu -b sd imx-boot-imx8mn-flash-evk.bin   (program bootloader to sd card)

during programing bootloader to flash on board, you can see logs on console.

so you don't need to use debugger, only need USB OTG port.

>> About "Error: HID(W):LIBUSB_ERROR_TIMEOUT"

If users run uuu command on windows 7 command line, probably the error will occur. root cause is USB driver for windows 7.

>> About checking hardware design.

At the same time, you need to carefully check the hardware design: eMMC IO level matching, SD card level matching. For example, the CPU side should be 1.8V IO, and eMMC should also be 1.8V IO. If the level match is wrong, an IO error will occur in the eMMC or SD card.

 

Hope above information is helpful to you.

Have a nice day!

B.R,

weidong

0 Kudos