DDRUTIL passes address bus testing where TF-A fails using identical DDR configurations

[JKell.6]

I've been validating my DDR interface with DDRUTIL through the CubeMX DDR Interactive which seems to pass the tests. When I boot TF-A it is failing both address bus testing for 1's and 0's. But I can run this same test through DDRUTIL and it passes. What am I overlooking here? As for DDR configuration in either case, the files are identical.

Here are the results of doing an address bus test (which per the comments is exactly what TF-A is doing)

DDR Interactive Results

DDR test #4 (AddressBus) triggered with parameters: 4096 0xC0000000

DDR test result: Pass

DDR test #4 (AddressBus) triggered with parameters: 67108864 0xC0000000

DDR test result: Pass

DDR test #4 (AddressBus) triggered with parameters: 67108864 0xC2000000

DDR test result: Pass

DDR test #4 (AddressBus) triggered with parameters: 67108864 0xC4000000

DDR test result: Pass

DDR test #4 (AddressBus) triggered with parameters: 67108864 0xC8000000

DDR test result: Pass

[PatrickF]

As you are on single x16 device, and if wires are not extremely long, you could also try to remove all the 56 ohms termination resistors you have (then VTT current will be close to 0 and btw VREF would be 'cleaner').

DC voltage on VREF is also important (VDDQ/2 +/-1% is acceptable I guess). Depend on how VTT is built, you might have issue (VTT DC voltage is not so important for terminations)

Regards.

[PatrickF]

I'm not expert of DDR behavior in that case, but sound a possible short term workaround.

Note that as far as I know uBoot is usually loaded at the end of the DDR, so size definition in relevant files matters.

[JKell.6]

Ha! Me neither, this is my first attempt at DDR. VTT is provided by a 1A LDO sourced by 1.35V with about 60uF capacitance. I'll take a look into those things you mentioned and might need to make some adjustments.

As for the DDR behavior, yeah I read somewhere yesterday about U-Boot being at the "end" of DDR so wondered whether my issue getting FSBL to load SSBL was related to that. But I just ran a DDRUTIL mem test over the whole 512MB available (per my config) and got a pass so seems that it's not DDR related. I'm trying a block sequential test (test 11) now over the whole memory to see what that does.