Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.com/letux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/letux-kernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/letux-u-boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/letux-u-boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
1) 2GB Pyra (C22 + M04) 2) 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation. * generally this 4GB Pyra is less stable. Could be RAM induced or something else. The test does not give a clear indication. * the 2GB Pyra runs stable in all configurations * 4GB and LPAE makes Linux boot fail more often * it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.local) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324-02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2-letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~#
Am Mittwoch, den 26.07.2017, 13:04 +0200 schrieb H. Nikolaus Schaller:
Hi,
one idea we had on IRC a while ago: Maybe try a different clockspeed for the DRAM to see if that changes thing. It supports multiple ones.
Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.com/let ux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/letux-k ernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
- 2GB Pyra (C22 + M04)
- 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.local) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324- 02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2- letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~# _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 26.07.2017 um 16:48 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mittwoch, den 26.07.2017, 13:04 +0200 schrieb H. Nikolaus Schaller:
Hi,
one idea we had on IRC a while ago: Maybe try a different clockspeed for the DRAM to see if that changes thing. It supports multiple ones.
Interesting idea.
If someone has a patch for me? I have no idea where this knob could be...
Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.com/let ux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/letux-k ernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
- 2GB Pyra (C22 + M04)
- 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced
or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.local) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324- 02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2- letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~# _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am 26.07.2017 um 16:54 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 26.07.2017 um 16:48 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mittwoch, den 26.07.2017, 13:04 +0200 schrieb H. Nikolaus Schaller:
Hi,
one idea we had on IRC a while ago: Maybe try a different clockspeed for the DRAM to see if that changes thing. It supports multiple ones.
Interesting idea.
If someone has a patch for me? I have no idea where this knob could be...
Ah, I got an idea where it is in the kernel: nowhere.
DRAM speed (EMIF) is set up in SPL, even before loading U-Boot.
But please consider in a theory that boot problems/hangup is only seen in kernel. I always got working DRAM in U-Boot to load the kernel at default DRAM speed.
Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.com/let ux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/letux-k ernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/letux-u -boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
- 2GB Pyra (C22 + M04)
- 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced
or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.local) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324- 02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2- letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~# _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
Am Mittwoch, den 26.07.2017, 17:00 +0200 schrieb H. Nikolaus Schaller:
Well, yes. But when U-Boot loads the kernel, a LOT less is going on in the system (not all hardware is initialized).
So if there really is some noise from somewhere, it could be it runs more stable with less clockspeed.
But please consider in a theory that boot problems/hangup is only seen in kernel. I always got working DRAM in U-Boot to load the kernel at default DRAM speed.
Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.c om/let ux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/l etux-k ernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/l etux-u -boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/l etux-u -boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
- 2GB Pyra (C22 + M04)
- 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced
or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.l ocal) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324- 02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2- letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~# _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
Am 26.07.2017 um 17:17 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mittwoch, den 26.07.2017, 17:00 +0200 schrieb H. Nikolaus Schaller:
Well, yes. But when U-Boot loads the kernel, a LOT less is going on in the system (not all hardware is initialized).
So if there really is some noise from somewhere, it could be it runs more stable with less clockspeed.
Yes. Can't be excluded for sure yet.
Anyways someone with enough knowledge about the EMIF must provide a patch before I can test anything in that direction.
But please consider in a theory that boot problems/hangup is only seen in kernel. I always got working DRAM in U-Boot to load the kernel at default DRAM speed.
Hi, finally I found enough undisturbed time to run the tests I had planned for a long time.
I tested with a single SD card with Letux-Debian8.9-LXDE rootfs and overwriting kernel/U-Boot as required by:
a) letux-4.13-rc2 standard kernel - http://download.goldelico.c om/let ux-kernel/letux-4.13-rc2/ b) letux-4.13-rc2 LPAE kernel - http://download.goldelico.com/l etux-k ernel/letux-4.13-rc2-lpae/
A) U-Boot with 2GB RAM config - http://download.goldelico.com/l etux-u -boot/Pyra+LC15/latest/ B) U-Boot with 4GB RAM config - http://download.goldelico.com/l etux-u -boot/Pyra+LC15-4GB/latest/
The 4GB EMIF config is here:
- 2GB Pyra (C22 + M04)
- 4GB Pyra (C48 + M28)
For each combination, I did try to boot, login and run "memtester 1500MB". memtester 3000MB is rejected for 2GB modes of course.
Here are the results:
Aa1) 2GB RAM visible, everything ok, memtester 1500M successful Aa2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ab1) 2GB RAM visible, everything ok, memtester 1500M successful Ab2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Ba1) U-Boot rejects device (SDRAM: identified size not same as expected) Ba2) 2GB RAM visible, boot sometimes hangs, memtester 1500M successful Bb1) U-Boot rejects device (SDRAM: identified size not same as expected) Bb2) 4GB RAM visible, boot more often hangs, memtester 1500M successful, memtester 3000M sometimes hangs after requesting 3GB, sometimes successful
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced
or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
BR, Nikolaus
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.0-rc2-letux-lpae+ (hns@iMac.l ocal) (gcc version 4.9.2 (GCC)) #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: Pyra-Handheld-V5.1 [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 16 MiB at 0x00000000fe000000 [ 0.000000] OMAP4: Map 0x000000027fd00000 to fe600000 for dram barrier [ 0.000000] On node 0 totalpages: 1043712 [ 0.000000] free_area_init_node: node 0, pgdat c108c240, node_mem_map ebff7000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 847104 pages, LIFO batch:31 [ 0.000000] OMAP5432 ES2.0 [ 0.000000] percpu: Embedded 17 pages/cpu @ebf8f000 s40704 r8192 d20736 u69632 [ 0.000000] pcpu-alloc: s40704 r8192 d20736 u69632 alloc=17*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1042176 [ 0.000000] Kernel command line: console= root=PARTUUID=6c9bc324- 02 rw rootfstype=ext4 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk [ 0.000000] log_buf_len: 8388608 bytes [ 0.000000] early log buf free: 63840(97%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 4093388K/4174848K available (8192K kernel code, 586K rwdata, 2240K rodata, 2048K init, 7999K bss, 65076K reserved, 16384K cma-reserved, 3372032K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0a00000 (10208 kB) [ 0.000000] .init : 0xc0e00000 - 0xc1000000 (2048 kB) [ 0.000000] .data : 0xc1000000 - 0xc1092900 ( 587 kB) [ 0.000000] .bss : 0xc1092900 - 0xc1862684 (8000 kB) [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16ac02862, max_idle_ns: 440795202218 ns [ 0.000006] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511085ns [ 0.000024] Switching to timer-based delay loop, resolution 162ns
...
[ 2.220127] Power Management for TI OMAP4+ devices. [ 2.225399] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.233704] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.239024] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2- letux-lpae+ #1297 [ 2.246970] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.253288] [<c020eaf0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.261417] [<c020afec>] (show_stack) from [<c084c048>] (dump_stack+0x98/0xd0) [ 2.269000] [<c084c048>] (dump_stack) from [<c055270c>] (check_preemption_disabled+0xec/0x124) [ 2.278042] [<c055270c>] (check_preemption_disabled) from [<c022032c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.287990] [<c022032c>] (pwrdm_set_next_pwrst) from [<c0e0cdd0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.297123] [<c0e0cdd0>] (omap4_mpuss_init) from [<c0e0d1ec>] (omap4_pm_init+0xf4/0x164) [ 2.305611] [<c0e0d1ec>] (omap4_pm_init) from [<c0e0a3f4>] (omap5_init_late+0x10/0x18) [ 2.313920] [<c0e0a3f4>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.322595] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.331356] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.340482] [<c0e00d94>] (kernel_init_freeable) from [<c085d678>] (kernel_init+0x8/0x10c) [ 2.349067] [<c085d678>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.357093] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.357491] ata1: SATA link down (SStatus 0 SControl 300)
...
letux login: root Password: Last login: Sat Jan 1 01:38:48 UTC 2000 on console Linux letux 4.13.0-rc2-letux-lpae+ #1297 SMP PREEMPT Mon Jul 24 13:08:10 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111820 kB MemFree: 3840616 kB MemAvailable: 4022440 kB Buffers: 9284 kB Cached: 213588 kB SwapCached: 0 kB Active: 145492 kB Inactive: 91496 kB Active(anon): 14208 kB Inactive(anon): 5392 kB Active(file): 131284 kB Inactive(file): 86104 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3156312 kB LowTotal: 723404 kB LowFree: 684304 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 14056 kB Mapped: 8260 kB Shmem: 5488 kB Slab: 32 kB SReclaimable: 0 kB SUnreclaim: 32 kB KernelStack: 720 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055908 kB Committed_AS: 47460 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13704 kB root@letux:~# memtester 3000m memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096 pagesizemask is 0xfffff000 want 3000MB (3145728000 bytes) got 2924MB (3067002880 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
Loop 2: Stuck Address : setting 14^C root@letux:~# _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Hi,
* H. Nikolaus Schaller hns@goldelico.com [170727 07:13]:
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
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
2. Revert commit 7abdb0e23e7b ("ARM: OMAP5: Add basic cpuidle MPU CSWR support") to see if it's somehow PM related
Regards,
Tony
Hi Tony,
Am 27.07.2017 um 16:19 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [170727 07:13]:
Now comes the difficult interpretation.
- generally this 4GB Pyra is less stable. Could be RAM induced
or something else. The test does not give a clear indication.
- the 2GB Pyra runs stable in all configurations
- 4GB and LPAE makes Linux boot fail more often
- it is possible to use the complete 4GB RAM, but not reliably
So I suspect a mixture of multiple effects. One makes the 4GB device I have tested less stable.
And the other could be an LPAE issue that makes 4GB only useable in certain good cases (I could imagine it depends on how the virtual paging mechanism randomly allocates RAM). But it could still be the 4GB RAM chips or config being less stable due to higher noise or power consumption or whatever.
Attached is an excerpt of the boot log and successful 3GB memtester output (the "BUG" occurs for non-lpae kernel as well - so it is not influencing the outcome).
Here are two suggestions to try to narrow this down a bit:
- 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.
What I could do was to use 2GB in first + 100M in second bank. This appears to show the same issues.
- 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.
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 [ 2.204151] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc3-letux-lpae+ #1315 [ 2.212082] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.218388] [<c020eae0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.226503] [<c020afec>] (show_stack) from [<c084bee8>] (dump_stack+0x98/0xd0) [ 2.234080] [<c084bee8>] (dump_stack) from [<c0552588>] (check_preemption_disabled+0xec/0x124) [ 2.243106] [<c0552588>] (check_preemption_disabled) from [<c022030c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.253050] [<c022030c>] (pwrdm_set_next_pwrst) from [<c0e0cdf0>] (omap4_mpuss_init+0xb4/0x23c) [ 2.262169] [<c0e0cdf0>] (omap4_mpuss_init) from [<c0e0d20c>] (omap4_pm_init+0xf4/0x164) [ 2.270656] [<c0e0d20c>] (omap4_pm_init) from [<c0e0a414>] (omap5_init_late+0x10/0x18) [ 2.278953] [<c0e0a414>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.287622] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.294441] ata1: SATA link down (SStatus 0 SControl 300) [ 2.302015] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.311136] [<c0e00d94>] (kernel_init_freeable) from [<c085d518>] (kernel_init+0x8/0x10c) [ 2.319703] [<c085d518>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.327714] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 2.335959] caller is pwrdm_set_next_pwrst+0x48/0x1d8 [ 2.341255] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc3-letux-lpae+ #1315 [ 2.349181] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 2.355483] [<c020eae0>] (unwind_backtrace) from [<c020afec>] (show_stack+0x10/0x14) [ 2.363596] [<c020afec>] (show_stack) from [<c084bee8>] (dump_stack+0x98/0xd0) [ 2.371166] [<c084bee8>] (dump_stack) from [<c0552588>] (check_preemption_disabled+0xec/0x124) [ 2.380191] [<c0552588>] (check_preemption_disabled) from [<c022030c>] (pwrdm_set_next_pwrst+0x48/0x1d8) [ 2.390132] [<c022030c>] (pwrdm_set_next_pwrst) from [<c0e0ce6c>] (omap4_mpuss_init+0x130/0x23c) [ 2.399346] [<c0e0ce6c>] (omap4_mpuss_init) from [<c0e0d20c>] (omap4_pm_init+0xf4/0x164) [ 2.407824] [<c0e0d20c>] (omap4_pm_init) from [<c0e0a414>] (omap5_init_late+0x10/0x18) [ 2.416126] [<c0e0a414>] (omap5_init_late) from [<c0e03560>] (init_machine_late+0x1c/0x90) [ 2.424782] [<c0e03560>] (init_machine_late) from [<c02018d8>] (do_one_initcall+0xa8/0x150) [ 2.433532] [<c02018d8>] (do_one_initcall) from [<c0e00d94>] (kernel_init_freeable+0x110/0x1d4) [ 2.442652] [<c0e00d94>] (kernel_init_freeable) from [<c085d518>] (kernel_init+0x8/0x10c) [ 2.451220] [<c085d518>] (kernel_init) from [<c0206ee8>] (ret_from_fork+0x14/0x2c) [ 2.459611] ThumbEE CPU extension supported. [ 2.464157] Registering SWP/SWPB emulation handler [ 2.475414] mmc0: new high speed MMC card at address 0001 [ 2.483023] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB [ 2.488487] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB [ 2.495345] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB
I had hoped that 0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9 also fixes this but it did not in 4.13-rc3.
BR, Nikolaus
* 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:
- 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, 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?
What I could do was to use 2GB in first + 100M in second bank. This appears to show the same issues.
OK
- 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.
Regards,
Tony
Hi Tony,
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:
- 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/let...
What I could do was to use 2GB in first + 100M in second bank. This appears to show the same issues.
OK
- 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/...
Hi,
* H. Nikolaus Schaller hns@goldelico.com [170811 13:25]:
Am 11.08.2017 um 16:46 schrieb Tony Lindgren tony@atomide.com: 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.
So after tinkering with pyra-4g this weekend, here's what seems to work based on very light testing:
1. Configure smps6 to 1.39V instead of 1.35V
So what does this mean? Not enough power from palmas or too low voltage for the 4GB DDR3 chip? Any ideas?
The 4GB DDR3 datasheet says "1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)", so maybe we need to configure it to 1.35V separately somehow?
2. Configure interleaving
Not sure if this is mandatory but needed for now it seems.
3. Use igepv5 ddr3 timings instead of Matthij's timings
Have not checked what's different.. I'll post my WIP patches shortly and let's figure it out, maybe Matthijs can spot the differences :)
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.
Well the 1.39V need seems weird..
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...
No idea about that, sounds like somebody who is more familiar with memory timings should try it out.
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/let...
Well something is still different with timings as the igepv5 timings work now :p
$ cat /proc/cmdline console=ttyS2,115200 mem=2032M@0x80000000 mem=2048M@0x300000000 debug earlyprintk earlycon $ free total used free shared buffers cached Mem: 4115788 186528 3929260 149784 0 149784 -/+ buffers/cache: 36744 4079044 Swap: 0 0 0
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):
I have not really needed JTAG for years, maybe a bit later thanks :)
Regards,
Tony
Hi, Great! Thanks! We may have doubled the noise on ddr3 power with 4gb chips. New pcb layout may already be better. Will try to test asap.
On the road.
Am 14.08.2017 um 06:39 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [170811 13:25]:
Am 11.08.2017 um 16:46 schrieb Tony Lindgren tony@atomide.com: 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.
So after tinkering with pyra-4g this weekend, here's what seems to work based on very light testing:
- Configure smps6 to 1.39V instead of 1.35V
So what does this mean? Not enough power from palmas or too low voltage for the 4GB DDR3 chip? Any ideas?
The 4GB DDR3 datasheet says "1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)", so maybe we need to configure it to 1.35V separately somehow?
- Configure interleaving
Not sure if this is mandatory but needed for now it seems.
- Use igepv5 ddr3 timings instead of Matthij's timings
Have not checked what's different.. I'll post my WIP patches shortly and let's figure it out, maybe Matthijs can spot the differences :)
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.
Well the 1.39V need seems weird..
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...
No idea about that, sounds like somebody who is more familiar with memory timings should try it out.
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/let...
Well something is still different with timings as the igepv5 timings work now :p
$ cat /proc/cmdline console=ttyS2,115200 mem=2032M@0x80000000 mem=2048M@0x300000000 debug earlyprintk earlycon $ free total used free shared buffers cached Mem: 4115788 186528 3929260 149784 0 149784 -/+ buffers/cache: 36744 4079044 Swap: 0 0 0
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):
I have not really needed JTAG for years, maybe a bit later thanks :)
Regards,
Tony
On 14 August 2017 at 06:39, Tony Lindgren tony@atomide.com wrote:
- Configure smps6 to 1.39V instead of 1.35V
So what does this mean? Not enough power from palmas or too low voltage for the 4GB DDR3 chip? Any ideas?
One thought that crossed my mind is that the 60Ω termination value configured in the ram might be inappropriate with two ranks. This value is configured in bits 24-26 of sdram_config: 0 = no termination 2 = 120Ω 1 = 60Ω
I think it would be worth testing 120Ω termination or even no termination at all (this should work if the drive strength on the omap side matches the traces to ram, and would reduce power consumption).
The 4GB DDR3 datasheet says "1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)", so maybe we need to configure it to 1.35V separately somehow?
No
- Configure interleaving
Not sure if this is mandatory but needed for now it seems.
It is desirable for performance.
- Use igepv5 ddr3 timings instead of Matthijs' timings
Have not checked what's different.. I'll post my WIP patches shortly and let's figure it out, maybe Matthijs can spot the differences :)
I think I checked what igep did, but I can take another look.
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...
That's determined automatically using hw leveling. The ram issue has however often manifested itself as a hw leveling failure, since it's a bit sensitive to noise and such.
Matthijs
* Matthijs van Duin matthijsvanduin@gmail.com [170814 02:31]:
On 14 August 2017 at 06:39, Tony Lindgren tony@atomide.com wrote:
- Configure smps6 to 1.39V instead of 1.35V
So what does this mean? Not enough power from palmas or too low voltage for the 4GB DDR3 chip? Any ideas?
One thought that crossed my mind is that the 60Ω termination value configured in the ram might be inappropriate with two ranks. This value is configured in bits 24-26 of sdram_config: 0 = no termination 2 = 120Ω 1 = 60Ω
I think it would be worth testing 120Ω termination or even no termination at all (this should work if the drive strength on the omap side matches the traces to ram, and would reduce power consumption).
OK will give it a try hopefully at some point later on tonight.
The 4GB DDR3 datasheet says "1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)", so maybe we need to configure it to 1.35V separately somehow?
No
OK
- Configure interleaving
Not sure if this is mandatory but needed for now it seems.
It is desirable for performance.
But also seemed necessary to have somehow based on brief my testing last night :)
Regards,
Tony
On 14 August 2017 at 16:13, Tony Lindgren tony@atomide.com wrote:
- Configure interleaving
Not sure if this is mandatory but needed for now it seems.
It is desirable for performance.
But also seemed necessary to have somehow based on brief my testing last night :)
Well, if highmem interleaving is disabled then the memory ranges are: 2G @ 0x80000000 (first GB of emif 0 and 1 interleaved) 1G @ 0x200000000 (second GB of emif 0) 1G @ 0x3c0000000 (second GB of emif 1)
* Matthijs van Duin matthijsvanduin@gmail.com [170814 02:31]:
On 14 August 2017 at 06:39, Tony Lindgren tony@atomide.com wrote:
- Configure smps6 to 1.39V instead of 1.35V
So what does this mean? Not enough power from palmas or too low voltage for the 4GB DDR3 chip? Any ideas?
One thought that crossed my mind is that the 60Ω termination value configured in the ram might be inappropriate with two ranks. This value is configured in bits 24-26 of sdram_config: 0 = no termination 2 = 120Ω 1 = 60Ω
I think it would be worth testing 120Ω termination or even no termination at all (this should work if the drive strength on the omap side matches the traces to ram, and would reduce power consumption).
So far it seems that just changing your original timings to have 0 for termination work with increased voltage possibly the same way as the igepv5 settings.
With termination at 2 I don't think I got u-boot to load at all.
Regards,
Tony
Okay, got some replies from my distributor. The RAM is tested to work with 1.35V.
He's got some ideas though:
* The timings are DIFFERENT when running with 400MHz (DDR3-800) and often not in the datasheets. If we're running at that speed, we might have to adjust those. The timings can be found on the JEDEC Specification on page 170 and later (I'll send the document to you via Mail, as that's not public).
* Also, if we're running at low speed, the DLL can interfere with the RAM. This can be disabled via Mode-Register (might be something we can try).
* As it's dual rank, it could be the layout needs to be adjusted (as it has more load on the lines). However, then I guess it would run unstable at 1.4V as well, wouldn't it?
Anyways, that DLL and the timings are our best guess for now, I think.
* Michael Mrozek EvilDragon@openpandora.org [170817 06:38]:
Okay, got some replies from my distributor. The RAM is tested to work with 1.35V.
He's got some ideas though:
- The timings are DIFFERENT when running with 400MHz (DDR3-800) and
often not in the datasheets. If we're running at that speed, we might have to adjust those. The timings can be found on the JEDEC Specification on page 170 and later (I'll send the document to you via Mail, as that's not public).
- Also, if we're running at low speed, the DLL can interfere with the
RAM. This can be disabled via Mode-Register (might be something we can try).
Setting bit 21 to disable ddr3 dll together with termination set to 2 helps with the issue I was seeing where u-boot is having hard time starting. So I'm currently using config value of 0x62a51b3a.
At 1.35V, kernel still keeps hanging all the time during boot so no changes there.
- As it's dual rank, it could be the layout needs to be adjusted (as it
has more load on the lines). However, then I guess it would run unstable at 1.4V as well, wouldn't it?
Anyways, that DLL and the timings are our best guess for now, I think.
I believe we're already using jedec timings. And they work with 1.42V and above.. I don't quite see how the timings would be affected by the voltage?
Regards,
Tony
On 17 August 2017 at 15:38, Michael Mrozek EvilDragon@openpandora.org wrote:
- The timings are DIFFERENT when running with 400MHz (DDR3-800) and
often not in the datasheets.
The datasheet of the RAM does specify the timings to be used for DDR3-800, and we are using them. These timings are also the same as for the single-rank ram.
- Also, if we're running at low speed, the DLL can interfere with the
RAM. This can be disabled via Mode-Register
Uhh, no, the DLL should normally always be enabled.
DLL-disabled mode is only for running ram at speeds lower than the minimum clock frequency (333 MHz), and the timings in that mode are unspecified.
On 17 August 2017 at 16:49, Matthijs van Duin matthijsvanduin@gmail.com wrote:
On 17 August 2017 at 15:38, Michael Mrozek EvilDragon@openpandora.org wrote:
- The timings are DIFFERENT when running with 400MHz (DDR3-800) and
often not in the datasheets.
The datasheet of the RAM does specify the timings to be used for DDR3-800, and we are using them. These timings are also the same as for the single-rank ram.
Ignore me, I wasn't awake yet. I was confusing the pyra with the beaglebone I think :-/
I think you can mostly get away with using DDR3-1066 parameters at 400 MHz, although it would unnecessarily slow. A few parameters need to be adjusted however, like the max time a row is allowed to be open (tRAS_max) and the refresh interval.
* Matthijs van Duin matthijsvanduin@gmail.com [170817 07:56]:
On 17 August 2017 at 16:49, Matthijs van Duin matthijsvanduin@gmail.com wrote:
On 17 August 2017 at 15:38, Michael Mrozek EvilDragon@openpandora.org wrote:
- The timings are DIFFERENT when running with 400MHz (DDR3-800) and
often not in the datasheets.
The datasheet of the RAM does specify the timings to be used for DDR3-800, and we are using them. These timings are also the same as for the single-rank ram.
Ignore me, I wasn't awake yet. I was confusing the pyra with the beaglebone I think :-/
I think you can mostly get away with using DDR3-1066 parameters at 400 MHz, although it would unnecessarily slow. A few parameters need to be adjusted however, like the max time a row is allowed to be open (tRAS_max) and the refresh interval.
We have omap_ddr_clk() return 531840000 in u-boot, so not 400 MHz. But since the current timings work at 1.42V, I don't see why they would need to be tweaked for 1.35V.
Regards,
Tony
On 17 August 2017 at 17:48, Tony Lindgren tony@atomide.com wrote:
We have omap_ddr_clk() return 531840000 in u-boot, so not 400 MHz. But since the current timings work at 1.42V, I don't see why they would need to be tweaked for 1.35V.
They shouldn't have to be. I'm not sure why 400 MHz was brought up in the first place, I assumed perhaps as experiment (although I'm not sure what exactly we would learn from it).
* Matthijs van Duin matthijsvanduin@gmail.com [170817 08:59]:
On 17 August 2017 at 17:48, Tony Lindgren tony@atomide.com wrote:
We have omap_ddr_clk() return 531840000 in u-boot, so not 400 MHz. But since the current timings work at 1.42V, I don't see why they would need to be tweaked for 1.35V.
They shouldn't have to be. I'm not sure why 400 MHz was brought up in the first place, I assumed perhaps as experiment (although I'm not sure what exactly we would learn from it).
The voltage affects slew rate though as whatever pull resistance on lines stays the same for different voltages, right?
Like ED pointed out, check out table 72 vs 73 in the ddr3 data sheet.
Regards,
Tony
On Do, 2017-08-17 at 17:58 +0200, Matthijs van Duin wrote:
400MHz speed would be for DDR3-800. That was brought up because the memory distributor mentioned that you have different timings with different speeds.
He has no idea which speed we're using. I just summarized his reply here :)
On 17 August 2017 at 17:48, Tony Lindgren tony@atomide.com wrote:
We have omap_ddr_clk() return 531840000 in u-boot, so not 400 MHz. But since the current timings work at 1.42V, I don't see why they would need to be tweaked for 1.35V.
They shouldn't have to be. I'm not sure why 400 MHz was brought up in the first place, I assumed perhaps as experiment (although I'm not sure what exactly we would learn from it).
Hi,
We have omap_ddr_clk() return 531840000 in u-boot, so not 400 MHz. But since the current timings work at 1.42V, I don't see why they would need to be tweaked for 1.35V.
So DDR3-1066.
Well, it would still be interesting to try whether they will behave differently with 1.35V if they're running slower.
---
-
Dr. H. Nikolaus Schaller -
H. Nikolaus Schaller
-
Matthijs van Duin -
Michael Mrozek -
Tony Lindgren