Am 11.08.2017 um 16:46 schrieb Tony Lindgren <tony@atomide.com>:

* H. Nikolaus Schaller <hns@goldelico.com> [170801 07:26]:
Am 27.07.2017 um 16:19 schrieb Tony Lindgren <tony@atomide.com>:

Here are two suggestions to try to narrow this down a bit:

1. Try with just 1GB of 4GB enabled instead of 2GB to see if
that works reliably

Well, I tried but was not able to easily tweak U-Boot to use just 1GB.
U-Boot did hang then.

Got my pyra 4G board set up last night here,

fine!

and I noticed
it would hang often while booting even with 2GB and no LPAE.
I only saw any kind of oops once or twice, most of the time
it just hung. Is this what you're seeing too?

Yes. 4GB CPU board randomly hangs - or succeeds to boot. 2GB boards

seem to boot fine every time.

Significant differences:

* different DDR3 chips (dual-die vs. single-die and different brand

* different U-Boot EMIF setup - 2GB board uses the same as OMAP5EVM plus one bit set [1] for "impedance calibration" or the system would not work with CPU clock > 1GHz

That is the reason why we don't know for sure if it is a SW or HW effect.

It could also be HW induced because SW setup is not optimized.

AFAIK, there is a DRA7 tool to calculate some EMIF parameter block

which takes wire lengths from SoC to DDR3 into account. The EMIF

seems to be able to add some picoseconds here and there...

We haven't done (and probably can't do) that for OMAP5 and Pyra.

And I don't exactly know where Mattijs got our EMIF setup from (maybe

IGEP5 wich different DDR3 PCB layout):

What I could do was to use 2GB in first + 100M in second bank. This
appears to show the same issues.

OK

2. Revert commit 7abdb0e23e7b ("ARM: OMAP5: Add basic cpuidle
MPU CSWR support") to see if it's somehow PM related

Didn't show a noticeable effect either.

OK

Just a note: what I see since 4.13-rc1 is

[ 2.151973] omap_vc_init_channel: No PMIC info for vdd_core
[ 2.157937] omap_vp_init: No PMIC info for vdd_core
[ 2.163111] omap_vc_init_channel: No PMIC info for vdd_mm
[ 2.168767] omap_vp_init: No PMIC info for vdd_mm
[ 2.173800] omap_vc_init_channel: No PMIC info for vdd_mpu
[ 2.179612] omap_vp_init: No PMIC info for vdd_mpu
[ 2.185218] Power Management for TI OMAP4+ devices.
[ 2.190520] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
[ 2.198816] caller is pwrdm_set_next_pwrst+0x48/0x1d8

Is this with just the 4G model? If there is a memory issue,
the oopses can be random all over the place.

I think I did one run on a 2GB model and it is there as well.

Most likely a general kernel bug not related to RAM. And introduced

by some 4.13-rc1 patch.

The 4GB hangs never occurred during U-Boot and usually come at

around 7 seconds after kernel start but symptoms are very random

(kernel oops, paging faults, hang without notice).

Hope this helps you to find something...

PS: if you can use a JTAG adapter, I could send you a SD-Card shaped

PCB with solder points for the OMAP5 JTAG signals. Here is a photo

(of the uncut PCB - I haven't access to a better photo this week):