Hi, I've been lurking for quite some time, your post got me curious enough to register!
Welcome to the forum!
I assume you are aware that igepv5 works with LPAE and 4GB
Actually I was, yet I had managed to completely forget about that one! It has also been ported to a newer u-boot by rcn:
https://github.com/RobertCNelson/Bo.../0001-IGEPv5-Added-IGEPv5-board-support.patch
I see absolutely nothing noteworthy in it with regard to memory setup. They configure 2 ranks in the geometry, enable impedance calibration for both of them, make some unnecessary changes to LISA section mapping, and inform the kernel. I guess I should just have faith and configure it.
I got a bit side-tracked by trying to understand the phy init better, trying to get the u-boot equivalent of earlycon working (sigh), etc.
Oh, fun fact: while exploring the ram init code I realized that u-boot-2016.11 on omap5/dra7 entirely neglects to enable ram-side impedance calibration! Whoops
I'm referring to zq_config bits 30-31 (for rank 0-1), which must be set to make EMIF send commands to the RAM chips to make them calibrate their drivers and ODT. Maybe it accidently got restructured out at some point, haven't checked yet.
mem=2032M@0x80000000 mem=2048M@0x300000000
Via kernel parameters instead of DT... not very pretty, but hey if it works...
I'm guessing they did it this way because they didn't have
98cc4544d65c? ("ARM: dts: Add support for more than 2GB of memory for omap5")
And I think there's the second cpu startup loop and whatever other boot rom stuff is at the 2032-2048
No, I'm pretty sure second cpu goes straight from ROM to linux. My first guess would be that the 16M@0xff000000 is intended for use by the multimedia firmware running on various subsystems. Or maybe it just gets cargo-culted around with the original reason lost in time ;-)
Also n-tuple-check the pin muxing for cke1 and ncs1..
All DDR3 signals have dedicated pins, no pinmux. There's a bit of I/O config for them, but the control signals (cas, ras, reset, we, cs0, cs1, ck0, cke1, odt0, odt1) are all grouped together and use the same settings (in byte at 0x4a002e37).