[Letux-kernel] 2GB vs. 4GB Pyra RAM tests

H. Nikolaus Schaller hns at goldelico.com
Fri Aug 11 22:25:38 CEST 2017


Hi Tony,

> Am 11.08.2017 um 16:46 schrieb Tony Lindgren <tony at atomide.com>:
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [170801 07:26]:
>>> Am 27.07.2017 um 16:19 schrieb Tony Lindgren <tony at 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):

http://git.goldelico.com/?p=gta04-uboot.git;a=blobdiff;f=board/goldelico/letux-cortex15/lc15.c;h=280da2095da9a780475fe3d59e79d283b050f02d;hp=709865cbe0f10d389634924d3b57c5731c184429;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8;hpb=be096ca0c2b204897b84c45e709511184b3a4059

> 
>> 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...

BR,
Nikolaus

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):



[1]: http://git.goldelico.com/?p=gta04-uboot.git;a=blobdiff;f=arch/arm/cpu/armv7/omap5/sdram.c;h=684467cb5fa5db6080cf38ce56ff23f0919426a2;hp=7712923d8572072a11566f44067fd2374531010c;hb=918c4c46104714a3cfede004a8880a9d04e3153a;hpb=dc091458762ce153413027794639f90aa9752810


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170811/7ae216b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BDE585b9a88b57c8_05_seite1.jpg
Type: image/jpeg
Size: 32475 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170811/7ae216b2/attachment-0001.jpg>


More information about the Letux-kernel mailing list