Debugging U-Boot on new bare board

[smiller2]

I have a new bare board.  I am trying to get U-Boot to run, but so far not successful.   I have followed the steps in CodeWarrior for ARMv8 Using in u.pdf  .    I programmed the QSPI flash at 0x00100000  the the file generated by flex-builder.    However, when I attempt to execute, it always goes immediately into the weeds.   

I was suspecting that this is a issue with the hand-off from the multiple bootloader sections since the defconfig that flex-builder is running is a "tfa" version.   I programmed both the binaries, produced by the "atf" build option, but still no go.   The debugger starts up, but then goes to unknown code immediately.   When I stop it, there are two cores running.   One is stuck at address  0x10000384 and the other at address 0xfbe00000.  

Questions:

1.  Can I simplify the boot process to not use secure boot or trusted firmware?

2.  Is there a way to step through the bootloader process to figure out where it is going bad?

3. Are there any other app notes on bring a new board up with U-Boot?

4.  DRAM initialization is still a problem for me.  However, I am assuming that U-Boot will at least start running as its running from Flash.   At what point would it be going to DRAM?

4.  Flex-Builder is running on another machine as a Virtual Box.   So, the code is not built on the machine running Code Warrior.  Code Warrior is installed an running on a Lab PC only.   Are there any documents on linking back the software for debugging purposes?     I did copy and link to the u-boot executable. 

Thanks.

[smiller2]

I found that my ddr_init.c  was not being compiled because of errors in the \firmware\atf\plat\nxp directory.   When I created my custom board in that directory, I did not properly reconfigure it.    I really don't know how to properly add a board or platform there and basically had to hack it.   Once my code was part of the build, then I got the BL2 bootloader to run.   It now crashes on BL3 as shown below:

NOTICE: 2 GB DDR4, 64-bit, CL=11, ECC off
NOTICE: BL2: v1.5(release):LSDK-20.12-dirty
NOTICE: BL2: Built : 15:07:02, Jun 9 2021
NOTICE: BL2: Booting BL31

(It is reporting "dirty" because of the hacks that  I added.)

The fip_uboot.bin I am programming to 0x00100000  in the QSPI.    If I delete that section then the message change:

NOTICE: 2 GB DDR4, 64-bit, CL=11, ECC off
NOTICE: BL2: v1.5(release):LSDK-20.12-dirty
NOTICE: BL2: Built : 15:07:02, Jun 9 2021
ERROR: BL2: Failed to load image (-2)
Authentication failure

So,  I think it is finding the BL3 bootloader.   However, I do not have a clue as to what is happening with the launch of that bootloader.   I tried to enable more printouts, but I cannot find out how to do that from flex-builder.    I tried adding LOG_LEVEL=60 to make it higher than the verbose level, but it just seemed to ignore it. 

How do I change the LOG_LEVEL or turn on DEBUG when using flex-builder?

What is the recommended way to debug problems with executing the bootloaders?

Thanks.

[yipingwang]

BL2 initializes the DRAM, then BL2 loads BL31, BL32, and BL33 images to the DDR memory after validating these images. 

There is problem in DDR controller initialization section in ATF code, so there is problem to load images to DRAM.

Please use QCVS DDR tool to assist you to calculate and optimize DDR controller initialization parameters, then use these parameters in ATF source code. 

You could use static timing method to configure DDR timing parameters. Define macro “CONFIG_STATIC_DDR” in plat/nxp/<SOC>/<Board>/plafform_def.h to enable discrete DDR timings. Define board_static_ddr() function and structure ddr_cfg_regs in file ddr_init.c

For compiling atf with debugging message, you could go to atf source code folder packages/firmware/atf, please add "DEBUG :=1" in Makefile, then go back to flexbuild_lsdk2012 folder run the command "flex-builder -c atf -m <platform> -b <type>"

[smiller2]

So I found that it actually getting stuck in the BL2 bootloader.   When I reloaded both portions of the QSPI,  I forgot to reconfigure the serial port on the PC after a reboot.   That caused me to miss the output it generated.  When I reconfigured the serial port and rebooted again, then I get messages about failed DDR configuration and

NOTICE: BL2: v1.5(release):LSDK-20.12
NOTICE: BL2: Built : 14:04:20, Jun 8 2021

So,  how are these multiple stages of bootloader debugged in Code Warrior?   These are not part of U-Boot so loading the U-Boot executable for symbols will not help me.

Thanks.

[yipingwang · Accepted solution]

u-boot debugging please refer to

https://community.nxp.com/t5/CodeWarrior-for-QorIQ-Knowledge/Use-CodeWarrior-for-ARMv8-to-Debug-U-bo...

DDR initialization porting in TFA, please refer to section “5.2.1.1 TF-A DDR Driver” in LSDK 20.12 document.

The DDR driver supports the following board level applications for DDR:

• DIMM: Driver reads SPD for configuring DDR timing parameters
• Mock DIMM: Hardcoded timing in place of reading SPD
• Discrete DDR: Driver requires a static DDR configuration to be added

When a board design uses DIMM module for dynamic memory configuration. _init_ddr function uses DDR board parameters to read the attached SPD and configure the DDR controller

When a board design uses fixed or discrete DDR, hardcoded or static timing can be used to configure DDR timing parameters. Define macro “CONFIG_DDR_NODIMM” in plat/nxp/<SOC>/<Board>/platform_def.h to enable MOCK DIMM support. Define function “ddr_get_ddr_params” and structure dim_params in ddr_init.c file.

When a board design uses fixed or discrete DDR, static timing can be used to configure DDR timing parameters. Define macro “CONFIG_STATIC_DDR” in plat/nxp/<SOC>/<Board>/plafform_def.h to enable discrete DDR timings. Define board_static_ddr() function and structure ddr_cfg_regs in file ddr_init.c

You could use QCVS DDR tool to assist you to calculate and optimize DDR controller initialization parameters. Please refer to the following document and the attached user manual.

https://community.nxp.com/t5/Qonverge-Knowledge-Base/DDR-Controller-Configuration-on-LS2085-LS2080-B...

[smiller2]

To close out the topic,  I did get U-Boot to execute completely.    The final issues were:

1.  I had not properly  updated code in \packages\firmware\atf\plat\nxp  (I suggest reading all files in the folder and then realizing while parts of the file names it is going to append.)

2.  The DDR configuration settings were good enough to get through DDR Init and some simple stuff but not good enough to actually execute code from.   The BL2 bootloader would execute right up to the jump to BL3 and then die since BL3 is going to run from DRAM.    Getting the proper DDR4 DRAM settings is very difficult for me since the Validator will not run properly on my board.   This documented in other posts. 

The tip-off that it is a DDR problem is to go and dump the DDR registers with CCS after the bootloader crashes.   If address E40 shows error bits set, then you can figure that the crash was due to data corruption when it tried to read the DRAM. 

I should note that I never did learn how to really debug U-Boot with the CodeWarrior TAP.   Once I got the BL3 bootloader running, then remainder of the code executed without errors.