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?
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.
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.
Solved! Go to Solution.
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.
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
------------+----+------+----+-------------------------------------------------
@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.
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.
@pikorn
Hello,
App note AN12853 ( i.MX ROMs Log Events ) may be also helpful.
https://www.nxp.com/webapp/Download?colCode=AN12853
Regards,
Yuri.
@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