[U-Boot] Wrong RAM Size on Devkit8000

[U-Boot] Wrong RAM Size on Devkit8000

[Maxime Ripard]

Hi,

I'm currently testing u-boot 2013.04 with SPL on a Devkit8000 with 256MB
of RAM.

Trouble is, it only detects 128MB of RAM. The x-loader found on the NAND
detects 256MB and works perfectly with it.

I obviously tried to change the mcfg field of the timings structure to
be at MICRON_V_MCFG_165(256 << 20), however, while it obviously detects
256MB of RAM, it then crashes quite badly when booting to a userspace
(and actually using that much RAM I guess). It works perfectly fine
though with only 128MB of RAM, so I think the timings are ok.

-- Boot from the NAND, with stock uboot/x-loader from TimLL -----------
X-Loader 1.41
Starting OS Bootloader...


U-Boot 1.3.3-svn (Mar 16 2012 - 17:38:47)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 DevKit8000 Board + LPDDR/NAND
DRAM:  256 MB
NAND:  512 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit space key to stop autoboot:  0


-- Boot from the MMC, using vanilla u-boot 2013.04 ---------------------
U-Boot SPL 2013.04 (May 14 2013 - 16:12:21)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.04 (May 14 2013 - 16:12:21)

OMAP3530-GP ES3.1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
OMAP3 DevKit8000 + LPDDR/NAND
I2C:   ready
DRAM:  128 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
ethaddr not set, using Die ID
Die ID #5910000700000000015470c40101a01e
Net:   dm9000
Hit any key to stop autoboot:  0

Any ideas on how to solve this?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[U-Boot] Wrong RAM Size on Devkit8000

[Andreas Bießmann]

Dear Maxime Ripard,

(CCing Board Maintainer)

On 05/14/2013 04:25 PM, Maxime Ripard wrote:
> Hi,
> 
> I'm currently testing u-boot 2013.04 with SPL on a Devkit8000 with 256MB
> of RAM.
> 
> Trouble is, it only detects 128MB of RAM. The x-loader found on the NAND
> detects 256MB and works perfectly with it.
> 
> I obviously tried to change the mcfg field of the timings structure to
> be at MICRON_V_MCFG_165(256 << 20), however, while it obviously detects
> 256MB of RAM, it then crashes quite badly when booting to a userspace
> (and actually using that much RAM I guess). It works perfectly fine
> though with only 128MB of RAM, so I think the timings are ok.

I guess this is linux related. We have the same problem with tricorder
board here. Please have a look at linux kernel
a/a/mach-omap2/board-devkit8000.c and check the following line:

---8<---
	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
				  mt46h32m32lf6_sdrc_params);
--->8---

The mt64h32m32 is a 1Gb device which is 128MiB. I think is an leftover
from the very beginning of these bords in linux. Maybe in former days
the boot-loader did not initialize SDRAM correctly so it was required to
re-write the timing registers in linux. Nowadays this should be removed.

> -- Boot from the NAND, with stock uboot/x-loader from TimLL -----------
> X-Loader 1.41
> Starting OS Bootloader...
> 
> 
> U-Boot 1.3.3-svn (Mar 16 2012 - 17:38:47)
> 
> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
> OMAP3 DevKit8000 Board + LPDDR/NAND
> DRAM:  256 MB
> NAND:  512 MiB
> Using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Hit space key to stop autoboot:  0
> 
> 
> -- Boot from the MMC, using vanilla u-boot 2013.04 ---------------------
> U-Boot SPL 2013.04 (May 14 2013 - 16:12:21)
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.04 (May 14 2013 - 16:12:21)
> 
> OMAP3530-GP ES3.1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> OMAP3 DevKit8000 + LPDDR/NAND
> I2C:   ready
> DRAM:  128 MiB
> NAND:  512 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> ethaddr not set, using Die ID
> Die ID #5910000700000000015470c40101a01e
> Net:   dm9000
> Hit any key to stop autoboot:  0
> 
> Any ideas on how to solve this?

Patch u-boot to detect whether it needs to initialize 256MiB or 128MiB.
Initialize timings correctly and remove the mentioned kernel re-timing.
Patches are welcome (I havn't fixed the tricorder issue til now ... ;).

Best regards

Andreas Bie?mann

[U-Boot] Wrong RAM Size on Devkit8000

[Maxime Ripard]

Hi Andreas,

Le 15/05/2013 09:44, Andreas Bie?mann a ?crit :
> Dear Maxime Ripard,
> 
> (CCing Board Maintainer)
> 
> On 05/14/2013 04:25 PM, Maxime Ripard wrote:
>> Hi,
>>
>> I'm currently testing u-boot 2013.04 with SPL on a Devkit8000 with 256MB
>> of RAM.
>>
>> Trouble is, it only detects 128MB of RAM. The x-loader found on the NAND
>> detects 256MB and works perfectly with it.
>>
>> I obviously tried to change the mcfg field of the timings structure to
>> be at MICRON_V_MCFG_165(256 << 20), however, while it obviously detects
>> 256MB of RAM, it then crashes quite badly when booting to a userspace
>> (and actually using that much RAM I guess). It works perfectly fine
>> though with only 128MB of RAM, so I think the timings are ok.
> 
> I guess this is linux related. We have the same problem with tricorder
> board here. Please have a look at linux kernel
> a/a/mach-omap2/board-devkit8000.c and check the following line:
> 
> ---8<---
> 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
> 				  mt46h32m32lf6_sdrc_params);
> --->8---
> 
> The mt64h32m32 is a 1Gb device which is 128MiB. I think is an leftover
> from the very beginning of these bords in linux. Maybe in former days
> the boot-loader did not initialize SDRAM correctly so it was required to
> re-write the timing registers in linux. Nowadays this should be removed.

Ouch, yes, I didn't think to look in Linux to see if it was doing some
timings configurations. Thanks for the pointer.

Now, both by changing the mentioned line in U-boot and by removing these
settings, and it seems to be working fine now.

>> Any ideas on how to solve this?
> 
> Patch u-boot to detect whether it needs to initialize 256MiB or 128MiB.
> Initialize timings correctly and remove the mentioned kernel re-timing.
> Patches are welcome (I havn't fixed the tricorder issue til now ... ;).

I'm not familiar enough yet with this board and the OMAP so that I know
how to do this right know, but I'll figure out.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com