Yes, the memory initialization happens after the UART, so you will always see something on the console.
Here is an example of a module which didn’t work: Fail boot using both Flash and recovery SD
To troubleshoot, I will compare the boot output to another card of the same physical layout (G1). In this case, the manufacturer incorrectly programmed the bit mappings (dq_mapping) in the module’s SPD, causing the memory initialization to fail.
(DQ mapping allows individual bits of the DDR4 memory bus to be swapped to improve physical routing. These are all set out in the original designs uploaded to JEDEC, so there is no reason to mess with them!)
All the issues I have seen have been related to incorrect SPD data, either incorrect DQ mappings or even modules claiming to be entirely different physical designs! There are a couple of workarounds already in the firmware (ignoring the SPD / forcing specific settings) for some known ‘broken’ modules.
What CodeWarrior is doing is finding the optimal parameters (Clock Adjust + Write Levelling) for the specific memory layout, which is a function of how the DDR traces (wires) are routed on the mainboard and memory module. There is a ‘window’ of parameters that do work, so CodeWarrior will select the middle of the window as the optimal setting.
If you look at slide 38 in this NXP presentation, that basically shows the view in CodeWarrior when doing the calibration runs.
This process runs over JTAG, AFAIK it basically tries each possible setting combination (with some ‘educated guessing’ derived from the physical trace lengths we give it) and sees which ones operate successfully.