Unable to boot from eMMC after flashing with uuu

[dpog]

I'm having a problem booting from the eMMC. When I put the iMX8M mini in download-mode, i can flash it with the uuu Tool, but when I start the board with bootconfig "boot from emmc", nothing happens, except that it falls back to download-mode. When a bootable SD-card is inserted, the board boots from there, despite the bootconfig. I can even load the kernel from the mmc2 (eMMC) and boot it, so I'm sure that the uuu-tool writes to the right medium. I'm considering the possibility that the Tool just writes the Bootloader to RAM, so that it's no longer available after I power down and start with the other bootconfig. 

[JorgeCas]

Did you tried using an script? (for example .AUTO or .txt files), this is other option to flash on UUU tool. As a reference you can use the file that is on the precompiled image on i.MX8M mini.

There are the executed commands on UUU and you can run it with the next:

./uuu -b <name of your file>.auto

[dpog]

I tried that, but I still got the same result. The console states that the bootloader has been written, when I restart the device, I get no Bootlog, not even the SPL:

MMC write: dev # 2, block # 66, count 3083 ... 3083 blocks written: OK
Writing 'bootloader' DONE!
Detect USB boot. Will enter fastboot mode!
Detect USB boot. Will enter fastboot mode!

-- log ends here, would expect the SPL to print from here on after a restart --

[edwardtyrrell]

Hi @dpog,

I use a Yocto wic Honister image into eMMC on my iMX8M Mini EVK with these operations:

sw1101 bit 20=on, bit 19=off    To program

sudo uuu -b emmc_all core-image-base-imx8mm-lpddr4-evk.wic

(I have uuu in my path)

sw1101 bit 20-off, bit 19=on    To run 

Hope it helps.

[dpog]

Hi @edwardtyrrell,
the bootswitches are set correctly (I'm using a custom design, but the boot_cfg is set accordingly). When I try to boot from the eMMC I get a delay before the board switches to serial download mode, so I guess I at least wrote something to the eMMC, but well, nothing bootable.

I tried your command, it's now stuck after "SDP: initialize...", but I read about a possible solution to that earlier, so I'm gonna try that.

What irritates me is the fact, that I thought that I used that command myself earlier and got the "Can't find a valid IVT-Header" Error.... I must have done something different then.
I will try to resolve the "SDP: initialize..." problem and report back

[edwardtyrrell]

Hi @dpog 

I've attached a boot log of uuu and normal running if it helps. I'm using USB. As a reference, I can set the board into download with a debug serial port to monitor what's going on and it will sit there displaying nothing until I hit the enter on running UUU. Within a few seconds this will appear:

U-Boot SPL 2021.04-lf_v2021.04+gf7b43f8b4c (Mar 01 2022 - 07:31:56 +0000)
power_bd71837_init
DDRINFO: start DRAM init
DDRINFO: DRAM rate 3000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
SEC0: RNG instantiated
Normal Boot
Trying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 1793152 to 0x40400000...

Then as you say, about a 5 second delay then uboot starts then eventually the download. UUU passes all that across as far as I know.

Might help..

 Check this out https://community.nxp.com/t5/i-MX-Processors/Error-quot-Can-validate-IVT-header-quot-when-flashing-i... 

[dpog]

My console shows that too, but it seems to get stuck at some point. I attached the complete log from the console from powerup and uuu download.

Right now I found out that I can still use the u-boot prompt when entering CTRL+C at that point

[edwardtyrrell]

Hi @dpog 

The UUU log looks pretty good. You mentioned that you're using a custom board? Might be a good idea to chop your problem in half and try UUU and your build on an iMX EVK. If that works then something may be odd with your board. If the EVK fails then start looking at your build then UUU. 

"but it seems to get stuck at some point" Can you send that part of the debug log or add a bit more info?

[dpog]

It is "stuck" at the bottom of the log. But not really stuck, because I can still use u-boot prompt.

Yes, it's a custom board. With the evalkit uuu is working fine, so yes, the problem is indeed with the board.
As I understand it, the u-boot code determines the used boot medium and sets the uboot env accordingly, like mmcroot in board/freescale/common/mmc.c
When I print out my environment, this states mmcroot = /dev/mmcblk1p2, but the emmc should be mmcblk2. mmcdev on the other hand is set to 2, as wanted

[edwardtyrrell]

Hi @dpog 

I've just tried something.. After downloading with UUU I did a CTRL-C (as you mentioned) and returned to uboot; this is something I actually never do. What I normally do is after the end of the UUU download I touch nothing and power off my board. Once powered off I then return the programing dip switches back to the 'run' position. Do do have the two dips (at least) the toggle between program and run? These would normally be bits 19 and 20 of SW1101 on the EVK. Most iMX devices have a 'manufacturing mode' that is used to program the device. A never-been-programmed device defaults to this mode for ease in production but once programmed it needs to be powered up with the specific links set to reenter the mode - hence the dip switches. 

The confusing thing with downloaders like MFGTool and UUU is everything is ran out of RAM to program the device. MFGTool and UUU (most likely) provide their own uboot code and everything needed to upload a basic Linux image in RAM that will be used to flash itself - everything has to be 'off' the eMMC. So when you CTRL-C back to uboot you're not actually using the uboot that's just been flashed on the board. Hence at that point if you enter 'boot' in uboot it will hang somewhere unable to find any mount points.   

Cheers.

[dpog]

Hi @edwardtyrrell, our board has two boot switches and a recovery-button, when it's pressed the board starts in download mode.

When I manually change the mountpoint it boots completely. The problem still remains that after I power the board down and up again, the SPL written by uuu is not loaded, hence no u-boot and so on. So I believe my problem might reside somewhere in the SPL

[edwardtyrrell · Accepted solution]

Hi @dpog 

"our board has two boot switches and a recovery-button" - I've seen this terminology before, the recovery-button was the reset button and a very misleading. iMXs don't have a 'momentary' press switch download ability.

"when it's pressed the board starts in download mode." Still sounds like it's in manufacturing mode (programming mode). iMXs don't have a momentary switch download ability, it's set by links or dip switches. If it is stuck in manufacturing mode then every time the recovery-button (reset button) is pressed it will reset and start programming mode again. You may find that you can do a download with UUU straight after power up without touching the 'recovery-button' at all, if you can, you're definitely still in manufacturing mode and need to trace those dip/link boot lines.

"When I manually change the mountpoint it boots completely." Correct, because if you're still in manufacturing mode and running UUU's uboot, pointing the mountpoint to eMMC post program will boot the board. Then on the next repower you'll be back to where you are.

The problem still remains that after I power the board down and up again, the SPL written by uuu is not loaded, hence no u-boot and so on. So I believe my problem might reside somewhere in the SPL

I seen this sort of thing a number of times particularly with custom boards, and no offense to the hardware guys but they might say it's nothing to do with mode links. Grab the circuit for the EVK and examine the connections around SW1101 and compare them to your custom board. 

Also get your board's circuit out and trace the recovery-button and see if it just goes to the reset circuitry.

Hope you'll get to the bottom of this in time!

EDIT:

Go back to your evalkit (if this is an iMX EVK) and keep the dips in program/manufacturing mode at all times. Then see if you can duplicate everything you've mentioned i.e mountpoint to get it to boot after programming etc. If it's doing the same things as your custom board then it may help to prove what mode your boards in.. Also as it's the same chip and I imagine you've modelled your custom board off it, if the code works on the EVK it should work perfectly on the custom board proving your build.. It's doesn't matter if you're missing peripheral hardware as the drivers probe will fail and simply skip over. You should get to login.

[dpog]

Hi @edwardtyrrell 

First of all, thank you for your constructive input, our custom board is now booting as intended!

For anyone who might stumble upon this thread later in search for a similar solution I summarize our steps: As hinted by Edward our boot-config (DIP-switches) might be faulted, and/or the recovery button might not work as intended. For clarification, our board uses the Signals from the two bootswitches and the recovery-button to determine some of the boot_config signals and the bootmode, they are not directly send to the iMX. Via U-Boot and the gpio-interface I checked the ingoing signals boot_cfg[15:0], and there I found the missing straw. As only some of the 16 bits are set by the switches, others are set directly by pulling the pins up (pulling down is not necessary, done internally). I then traced the wrongly set bits to a set of resistors that were planned as not to be placed in the schematic (still in development), but when the board went into a hardware-modification, the resistors where placed and soldered on (wrong instructions for the modification), resulting in the wrong boot configuration. By removing the resistors the boot configuration was fixed and the board is now booting as intended.

I hope this will help others in the future facing similar problems, thanks again!

PS: the recovery button works as intended, it is not connected to the reset circuitry

[edwardtyrrell]

Hi @dpog 

Great news! Well done. Cracking problems in this field of expertise is often full of grey areas and lack of clear information but once an issue is solved it helps clarify what the facts are for next time. 

Cheers.

[JorgeCas]

Dear Dominik Poggel,

First of all, I need a little more information.

Are you using a custom board or the EVK board?

What is it your current UUU version? (Try to update to the last available version)

Could you please provide me the command to flash the board and .auto file?

Is it a custom image or NXP's precompiled image?

If is not booting from eMMC and goes to download mode after some time, this could by caused because is not detecting an eMMC device to boot or has not the correct value on the boot switches.

Also please double check the values on boot switches (the next figure is for i.MX 8M Mini EVKB):

Best regards.