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

[JKell.6]

Some additional information I discovered...

Using DDRUTIL I can get the same failure TF-A is giving me if I run all the tests (i.e. test 0). When I run all the tests test 4 will fail at the same address 0xc8000000. What's more interesting is if I run test 4 and start increasing the size of test 4 across 0xc0000000 - 0xc8000000 and 0xd0000000 - 0xd8000000 and so forth I can get passes. Here's a snippet

[JKell.6]

So is this test revealing a real hardware error on my address bus or is this an incorrect configuration thing? Maybe bus speed can be slowed to resolve? Being that I get conflicting results based on whether I run the command alone or inline with other tests is confusing.

[PatrickF]

Hi @Community member​ ,

Maybe look at DDR size have you populated on your board Vs the one in various config files.

Failing at 0xC8000000 could mean only 1Gbit (128MB) is available.

Regards,

[JKell.6]

Patrick, I found that if I reduce specified size in CubeMX from 8Gb to 4Gb I can get DDRUTIL to pass all tests along with TF-A. The way it's shown in CubeMX I think I was confused on how to specify. The part is a 1GB part (8Gb) but with a x16 bus which the way the field is listed it says:

Density for DDR3(L) 16bits [ ]

So my guess is that x16 makes the 8Gb become 4Gb or (2 * 4Gb = 8Gb). The DTS file shows it being a 512M address space and with a x16 bus that would be 1GB. Is this correct thinking?

[PatrickF]

Hi,

So, if my understanding is correct, you have a board with a single DDR3L x16 of 8Gbits (1GByte), right ?

The bus width only changes DDRCTRL/DDRPHYC settings, but neither affect the device density to be entered (number of bits inside the memory, i.e. 8Gbits) nor the amount of bytes available to the SW (i.e. 1GBytes).

Did you wire all required signals for largest density on your board (especially addresses A[15:0]) ?

Did you select width (i.e. x16) and the right density (i.e. 8Gb) in CubeMx ?

 

Regards.

[JKell.6]

Correct Patrick, Its a single DDR3L x16 of 8Gbits. Okay on how the bus width only affects the CTRL and PHY registers. Originally I did have the configuration set exactly has you've shown but I get failures when running tests like DDRUTIL test 0 which will run all the tests it will fail address bus test every time TF-A boot will fail its address bus test as well since it's the same test. What became really confusing is I could still do a simple single test on those address points, like test 4 in DDRUTIL and get a pass. By cutting the density in half it seems to fix the issue in both DDRUTIL and TF-A tests. And in reality I will never use even 512MB of DRAM so not a huge issue at the moment assuming I can get the rest of the process to work. As for wiring the DDR, yes A[15:0] are wired. Schematic is included here just in case you can find something I've missed.

What's interesting is I can now get through that initial TF-A (FSBL) boot where it want's to load FIP and it's getting stuck for like 30+ seconds then says it's downloading FIP but never does and just fails. So I'm wondering now if that's a related DDR issue.

[PatrickF]

Hi,

quickly looking at schematics point one potential problem

• Using VTT for DDR VREF is not recommended as VREF must be as clean as possible and VTT is noisy. As recommended in AN5031 and AN5122, you should either use one resistor divider from VDDQ on MP15 and memory side or use STPMIC1 dedicated output.

Maybe have also a look for potential soldering issues.

Regards.

[JKell.6]

Gotcha, yep I remember both of those app notes very well. I apparently overlooked that. Here's a snap shot of my VTT line even during running all DDRUTIL tests. That's the worst of it but maybe enough to cause an issue. It is around 200mVp-p. Reviewing the PCB those two signals VREFDQ and VREFCA are accessible and I could fix that.

 

Yeah, we've had these boards x-rayed and soldering was pretty well spot on but I suppose you can't catch everything with x-ray either.

[JKell.6]

So let me ask this, if I can get everything to work well at half the memory size spec'd compared to what's actually on the board. For example, I can set my density to 512MB and access memory from 0xC0000000 to 0xDFFFFFFF without any issue. That wouldn't cause any issue with FSBL and SSBL bring up, right? It's just not seeing/using all the memory actually available. I've actually performed DDRUTIL test 5 which tests memory integrity over 512MB and got a pass.