On 26 February 2017 at 22:24, Grazvydas Ignotas notasas@gmail.com wrote:
I've tried to find out why DRAM init fails and found something with the help of patch 0003, where it prints: "SDRAM: identified size not same as expected size identified: 4 expected: 40000000" so something goes wrong during setup.
I also seem to be getting this nearly every time I'm failing to get into u-boot. I have no idea why this is merely printed as a warning instead of the panic() it should be. I have no idea how it is possible that Nikolaus is sometimes able to boot normally after this message, since it means it didn't even pass a rudimentary memory test.
My impression is that ddr3 leveling is failing. EMIF has a history of buggy hardware leveling, and incremental (as opposed to full) leveling is still marked as not-supported for omap5 and dra7. I'm also seeing lots of error flags set in the phy after leveling, though curiously that's also the case when it does boot, so maybe the flags are just garbage. I'll see if I can print more informative debug info about what's going on during EMIF initialization.
There is a warm_reset() function that's used quite a bit by RAM init code
(emif-common.c)
Yes, which is suspicious. It is not guaranteed that warm reset implies EMIF has been initialized before. The correct way to record that initialization has been done for some module is by clearing its "context lost" bit in PRM, which exist for exactly that purpose.
However, warm_reset() may still be the right thing to check if extra steps are required when emif is not necessarily in a clean state as it is just after cold reset. I've noticed that an example of such is being unintentionally skipped thanks to a typo: https://github.com/mvduin/u-boot/commit/5435989af0ad70e7c219 4eca79232a3a2b1fcc18
This might at least explain why warm reset rarely seemed to resolve anything? Let's see if that problem now improves.
I also have to say the whole EMIF initialization logic in that file really looks quite hacky and convoluted. Remarks like this one (in an older revision of the file) are also not exactly confidence-inspiring: https://github.com/mvduin/u-boot/blob/6c70935d7525/arch/arm/cpu/armv7/omap-c...
Matthijs