Quantcast

512MB RAM showing up on older Overo COMs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

512MB RAM showing up on older Overo COMs

Scott Ellis
I have a project using some old Overo COMs < R2889.

Current uboot and kernel are showing 512MB of RAM,
but I'm pretty sure it should only be 256MB.

Predictably, the systems crash if you try to use any signficant
amount of memory. In my tests anything more then 80MB.

This sounds like a u-boot memory init problem.

I'm using u-boot 2016.05 (mainline with minor config changes to reduce
the memory footprint MLO), but I also tried 2015.07 from the meta-gumstix
repo with the associated patches. Same symptoms.

The kernel is 4.4.14 but I tried a 3.18 kernel, same thing.

The same u-boot/kernel combo works fine for a R3358 COM and any
of the Storm COMs.

I believe R3018/R3019 was when the switch to 512MB of RAM on
the Overos happened so this makes sense.

Anyone have the fix?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 512MB RAM showing up on older Overo COMs

Scott Ellis
This commit to u-boot

commit fe5d488fbef192188bcddb8774154bd5527e468b
Author: Arun Bharadwaj <arun@gumstix.com>
Date:   Tue Apr 28 16:55:29 2015 -0700

    overo: Split overo.c into spl.c, common.c and overo.c

    This separates the SPL-specific code from the u-boot-specific code for
    the Overo board following the discussion at
    http://lists.denx.de/pipermail/u-boot/2015-April/211622.html

    The code is split up into spl.c, overo.c and common.c (which
    has the code common to both)

    Signed-off-by: Arun Bharadwaj <arun@gumstix.com>


Changed the revision 0 board timings from this (in overo.c)

-       case REVISION_0: /* Micron 1286MB/256MB, 1/2 banks of 128MB */
-               timings->mcfg = MICRON_V_MCFG_165(128 << 20);
-               timings->ctrla = MICRON_V_ACTIMA_165;
-               timings->ctrlb = MICRON_V_ACTIMB_165;
-               timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
-               break;


to this (in spl.c)

+       case REVISION_0: /* Micron 1286MB/256MB, 1/2 banks of 128MB */
+               timings->mcfg = MICRON_V_MCFG_165(256 << 20);
+               timings->ctrla = MICRON_V_ACTIMA_165;
+               timings->ctrlb = MICRON_V_ACTIMB_165;
+               timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+               break;

That explains the 512 MB u-boot is reporting for revision 0 boards.

Switching this back to (128 << 20) results in 256 MB again.

Was this intentional or a mistake?

I ask because undoing this change upsets the kernel and it won't boot.
At least mine won't. I'm using an unmodified omap3-overo-tobi.dts.

Similarly leaving the u-boot 512MB change in and specifying the following
to the kernel command line

  mem=256M@0x80000000

also causes the kernel not to boot.

It looks like the kernel wants more then 256M of RAM.

This works okay

  mem=320M@0x80000000


Any ideas?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 512MB RAM showing up on older Overo COMs

Scott Ellis
257M is okay

root@overo:~# cat /proc/cmdline
console=ttyO2,115200n8 mem=257M@0x80000000 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

root@overo:~# free
              total        used        free      shared  buff/cache   available
Mem:         242988        5164      212072         184       25752      224244
Swap:             0           0           0

256M is not
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 512MB RAM showing up on older Overo COMs

Scott Ellis
Moving the relocation address for the dtb seems to make things happy.

The default was moving the dtb like this

    Kernel image @ 0x82000000 [ 0x000000 - 0x3e0a70 ]
    ## Flattened Device Tree blob at 88000000
       Booting using the fdt blob at 0x88000000
       Loading Device Tree to 8ffec000, end 8ffff0c1 ... OK

Setting the environment variable fdt_high to 0x8f000000 results
in a move like this that is not so close to the 256M limit

    Kernel image @ 0x82000000 [ 0x000000 - 0x3e0a70 ]
    ## Flattened Device Tree blob at 88000000
       Booting using the fdt blob at 0x88000000
       Loading Device Tree to 8efec000, end 8efff0c1 ... OK

That along with this change to the u-boot source

diff --git a/board/overo/spl.c b/board/overo/spl.c
index 5af780e..63daf68 100644
--- a/board/overo/spl.c
+++ b/board/overo/spl.c
@@ -27,7 +27,7 @@ void get_board_mem_timings(struct board_sdrc_timings *timings)
        timings->mr = MICRON_V_MR_165;
        switch (get_board_revision()) {
        case REVISION_0: /* Micron 1286MB/256MB, 1/2 banks of 128MB */
-               timings->mcfg = MICRON_V_MCFG_165(256 << 20);
+               timings->mcfg = MICRON_V_MCFG_165(128 << 20);
                timings->ctrla = MICRON_V_ACTIMA_165;
                timings->ctrlb = MICRON_V_ACTIMB_165;
                timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;

and now the kernel boots older COMs with only 256M of RAM

U-Boot 2016.05-jumpnow (Jul 14 2016 - 10:34:12 -0400)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Gumstix Overo board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
MMC:   OMAP SD/MMC: 0
Using default environment

root@overo:~# uname -a
Linux overo 4.4.14-jumpnow #1 Thu Jul 14 05:32:14 EDT 2016 armv7l armv7l armv7l GNU/Linux

root@overo:~# cat /proc/cmdline
console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

root@overo:~# free
              total        used        free      shared  buff/cache   available
Mem:         241972        5944      210644         192       25384      222620
Swap:             0           0           0

And the system no longer crashes when using the memory

root@overo:~# memtester 192M
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 192MB (201326592 bytes)
got  192MB (201326592 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          : setting  11
  ...

Newer COMs that really have 512 MB are not impacted.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 512MB RAM showing up on older Overo COMs

Akram Hameed
Nice work, Scott.

Also would be nice if the gumstix guys would chime in once in a while...

On Fri, Jul 15, 2016 at 1:00 AM, Scott Ellis <[hidden email]> wrote:
Moving the relocation address for the dtb seems to make things happy.

The default was moving the dtb like this

    Kernel image @ 0x82000000 [ 0x000000 - 0x3e0a70 ]
    ## Flattened Device Tree blob at 88000000
       Booting using the fdt blob at 0x88000000
       Loading Device Tree to 8ffec000, end 8ffff0c1 ... OK

Setting the environment variable fdt_high to 0x8f000000 results
in a move like this that is not so close to the 256M limit

    Kernel image @ 0x82000000 [ 0x000000 - 0x3e0a70 ]
    ## Flattened Device Tree blob at 88000000
       Booting using the fdt blob at 0x88000000
       Loading Device Tree to 8efec000, end 8efff0c1 ... OK

That along with this change to the u-boot source

diff --git a/board/overo/spl.c b/board/overo/spl.c
index 5af780e..63daf68 100644
--- a/board/overo/spl.c
+++ b/board/overo/spl.c
@@ -27,7 +27,7 @@ void get_board_mem_timings(struct board_sdrc_timings
*timings)
        timings->mr = MICRON_V_MR_165;
        switch (get_board_revision()) {
        case REVISION_0: /* Micron 1286MB/256MB, 1/2 banks of 128MB */
-               timings->mcfg = MICRON_V_MCFG_165(256 << 20);
+               timings->mcfg = MICRON_V_MCFG_165(128 << 20);
                timings->ctrla = MICRON_V_ACTIMA_165;
                timings->ctrlb = MICRON_V_ACTIMB_165;
                timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;

and now the kernel boots older COMs with only 256M of RAM

U-Boot 2016.05-jumpnow (Jul 14 2016 - 10:34:12 -0400)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Gumstix Overo board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
MMC:   OMAP SD/MMC: 0
Using default environment

root@overo:~# uname -a
Linux overo 4.4.14-jumpnow #1 Thu Jul 14 05:32:14 EDT 2016 armv7l armv7l
armv7l GNU/Linux

root@overo:~# cat /proc/cmdline
console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

root@overo:~# free
              total        used        free      shared  buff/cache
available
Mem:         241972        5944      210644         192       25384
222620
Swap:             0           0           0

And the system no longer crashes when using the memory

root@overo:~# memtester 192M
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 192MB (201326592 bytes)
got  192MB (201326592 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          : setting  11
  ...

Newer COMs that really have 512 MB are not impacted.




--
View this message in context: http://gumstix.8.x6.nabble.com/512MB-RAM-showing-up-on-older-Overo-COMs-tp4970984p4970992.html
Sent from the Gumstix mailing list archive at Nabble.com.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Loading...