IMX8M Mini stuck in Boot ROM

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

IMX8M Mini stuck in Boot ROM

Jump to solution
2,271 Views
pikorn
Contributor II

Overview

I have a new custom board which is failing to get into u-boot. UUU runs successfully, but JTAG shows that the IMX8 is still in the Boot ROM code. I have confirmed that the serial downloader is able to load u-boot code into the TCML (0x007E_XXXX) area by using JTAG to verify the memory contents of a known function in u-boot. However, it appears that the u-boot code is not executing.

What could be preventing the IMX8 from getting past the Boot ROM code? Are there any common mistakes here?

Software Debug Info

Here is a capture of the JTAG output in GDB, captured after UUU has loaded u-boot. This shows the PC in the Boot ROM area of memory, and the beginning of a u-boot function in the TCML area of memory.

 

(gdb) i reg
x0             0xf0000000          4026531840
x1             0x6                 6
x2             0x901dfb            9444859
x3             0x0                 0
x4             0xc1dc              49628
x5             0x901dfc            9444860
x6             0xffffffffffffffff  18446744073709551615
x7             0x0                 0
x8             0x0                 0
x9             0x235990ea          593072362
x10            0x5                 5
x11            0x908000            9469952
x12            0xf0000000          4026531840
x13            0x6                 6
x14            0x90e558            9495896
x15            0x90b5c0            9483712
x16            0x0                 0
x17            0x0                 0
x18            0x0                 0
x19            0x90b500            9483520
x20            0x235990ea          593072362
x21            0x90e6d8            9496280
x22            0x90c000            9486336
x23            0x30350480          808780928
x24            0x1                 1
x25            0x910000            9502720
x26            0x30390070          809042032
x27            0x900               2304
x28            0x0                 0
x29            0x901e80            9444992
x30            0x13dd8             81368
sp             0x901e80            0x901e80
pc             0x13ddc             0x13ddc
cpsr           0x200002cd          [ SP=1 EL=2 nRW=0 F I D C ]
fpsr           0x0                 0
fpcr           0x0                 0
ELR_EL1        0xbfd0c1c3d1950a0d  0xbfd0c1c3d1950a0d
ESR_EL1        0xf7f7fb9d          4160224157
SPSR_EL1       0x21b9485           35361925
ELR_EL2        0xbdb230891bc59095  0xbdb230891bc59095
ESR_EL2        0x75d6467a          1976977018
SPSR_EL2       0x120cfdc9          302841289
ELR_EL3        0xfb34              0xfb34
ESR_EL3        0x96000210          2516582928
SPSR_EL3       0x600003cd          1610613709
(gdb) x/2i 0x13dd8
   0x13dd8:	wfi
=> 0x13ddc:	b	0x13dd8
(gdb) x/5i board_early_init_f
   0x7e3b7c <board_early_init_f>:	stp	x29, x30, [sp, #-16]!
   0x7e3b80 <board_early_init_f+4>:	mov	w1, #0x0                   	// #0
   0x7e3b84 <board_early_init_f+8>:	mov	w0, #0x83                  	// #131
   0x7e3b88 <board_early_init_f+12>:	mov	x29, sp
   0x7e3b8c <board_early_init_f+16>:	bl	0x7eb370 <gpio_direction_output>

 

Information captured using JTAG-HS3 + openocd + gdb.

 

Hardware Notes

  • This is a custom board design.
  • Confirmed that the voltage supplies are as expected (using the PCA9450 PMIC).
  • Clock sources are active and at correct frequency.
  • BOOT_MODE pins are set to '01' or serial downloader mode.
  • ONOFF pin is pulled high with 100k resistor.

There is a small error on the PCB where NVCC_SNVS_1P8 from the LDO and 1V8 from the switcher, bot on the PMIC are tied together. As such, I'm not sure the sequences matches the NXP design, but we are seeing the correct voltages and the board is communicating through JTAG.

Labels (1)
0 Kudos
1 Solution
2,017 Views
pikorn
Contributor II

We found that our pull-up on POR_B was too weak. Once we replaced it with a stronger pull-up then I saw the expected BOOT_MODE being latched in as expected. At this point we were able to boot our u-boot image.

Yuri, thank you for all the help and guidance.

View solution in original post

5 Replies
2,114 Views
pikorn
Contributor II

Hi Yuri,

Thank you for the response.

The SRC_SBMR2 register indicates that the BOOT_MODE is eFUSE (00) rather than Software downloader (01). I have measure the votlage of the BOOT_MODE pins after power up and they are correct (01). I am working on verifying their state during power on to see if there is an issue. Is there any other way BOOT_MODE could be affected?

I attempted to check the BootROM logs, but the ROM Event Log Buffer BAR is pointing to 0x0. At this point, I assume this is because the BootROM has not run enough to initialize the BAR. Can you confirm that 0x5E0 is the correct BAR for an IMX8M Mini?

(gdb) x 0x05E0
0x5e0:  0x00000000

I also parsed the HAB Persistent Data logs with CST. I assume that these are not useful right now because the wrong BOOT_MODE is selected.

------------+----+------+----+-------------------------------------------------
Persistent  | T  |  L   | P  | Contents
Memory      | a  |  e   | a  |
Record      | g  |  n   | r  |
Type        |    |  g   |    |
            |    |  t   |    |
            |    |  h   |    |
------------+----+------+----+-------------------------------------------------
Event       |0xdb|0x0008|0x43| SRCE Field: 33 11 cf 00
            |    |      |    |             STS = HAB_FAILURE (0x33)
            |    |      |    |             RSN = HAB_INV_CSF (0x11)
            |    |      |    |             CTX = HAB_CTX_CSF (0xCF)
            |    |      |    |             ENG = HAB_ENG_ANY (0x00)
------------+----+------+----+-------------------------------------------------
Event       |0xdb|0x0014|0x43| SRCE Field: 33 0c a0 00
            |    |      |    |             STS = HAB_FAILURE (0x33)
            |    |      |    |             RSN = HAB_INV_ASSERTION (0x0C)
            |    |      |    |             CTX = HAB_CTX_ASSERT (0xA0)
            |    |      |    |             ENG = HAB_ENG_ANY (0x00)
            |    |      |    | Evt Data (hex):
            |    |      |    |  00 00 00 00 00 7e 0f c0 00 00 00 20
------------+----+------+----+-------------------------------------------------
Event       |0xdb|0x0014|0x43| SRCE Field: 33 0c a0 00
            |    |      |    |             STS = HAB_FAILURE (0x33)
            |    |      |    |             RSN = HAB_INV_ASSERTION (0x0C)
            |    |      |    |             CTX = HAB_CTX_ASSERT (0xA0)
            |    |      |    |             ENG = HAB_ENG_ANY (0x00)
            |    |      |    | Evt Data (hex):
            |    |      |    |  00 00 00 00 00 7e 0f e0 00 00 00 01
------------+----+------+----+-------------------------------------------------
Event       |0xdb|0x0014|0x43| SRCE Field: 33 0c a0 00
            |    |      |    |             STS = HAB_FAILURE (0x33)
            |    |      |    |             RSN = HAB_INV_ASSERTION (0x0C)
            |    |      |    |             CTX = HAB_CTX_ASSERT (0xA0)
            |    |      |    |             ENG = HAB_ENG_ANY (0x00)
            |    |      |    | Evt Data (hex):
            |    |      |    |  00 00 00 00 00 7e 10 00 00 00 00 04
------------+----+------+----+-------------------------------------------------

  

2,082 Views
Yuri
NXP Employee
NXP Employee

@pikorn 
Hello,

  According to Table 11 (ROM event log buffer address) of app note
AN12853: 0x9E0 is log buffer base address location (i.MX8Mm belongs
to i.MX mSCALE series).

  As for "the BOOT_MODE is eFUSE (00) rather than Software downloader (01)",
also please check the schematic. 

Regards,
Yuri.

0 Kudos
2,018 Views
pikorn
Contributor II

We found that our pull-up on POR_B was too weak. Once we replaced it with a stronger pull-up then I saw the expected BOOT_MODE being latched in as expected. At this point we were able to boot our u-boot image.

Yuri, thank you for all the help and guidance.

2,134 Views
Yuri
NXP Employee
NXP Employee

@pikorn 
Hello,

  App note AN12853 ( i.MX ROMs Log Events ) may be also helpful.

 

https://www.nxp.com/webapp/Download?colCode=AN12853

 

Regards,
Yuri.

0 Kudos
2,193 Views
Yuri
NXP Employee
NXP Employee

@pikorn 
Hello,

  Customers can analyze HAB persistent memory, which is used by HAB to store audit logs,
i.e. logs of various events and status results. Please refer to "README.hab_log_parser"
in the CST package.

https://www.nxp.com/webapp/Download?colCode=IMX_CST_TOOL_NEW

 

Regards,
Yuri

 

0 Kudos