[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Heiko Schocher]

since commit 3667cbeed5e3c4067e624e52a916b1ebb02c8f05
on beagle board the second sdram bank didn;t longer
work. Since this patch sdram settings just get copied
from bank a, but CMD_NOP, CMD_PRECHARGE, CMD_AUTOREFRESH
are not executed and after that mr register is also
not updated. This patch adds this for the bank b.

Signed-off-by: Heiko Schocher <hs@denx.de>
cc: Steve Sakoman <steve@sakoman.com>
cc: Sandeep Paulraj <s-paulraj@ti.com>
cc: Wolfgang Denk <wd@denx.de>
---
Wolfgang, this patch should also be added to u-boot-arm elf_reloc

 arch/arm/cpu/armv7/omap3/sdrc.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
index 2719bb5..3087096 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -149,6 +149,13 @@ void do_sdrc_init(u32 cs, u32 early)
 			&sdrc_actim_base1->ctrla);
 		writel(readl(&sdrc_actim_base0->ctrlb),
 			&sdrc_actim_base1->ctrlb);
+
+		writel(CMD_NOP, &sdrc_base->cs[cs].manual);
+		writel(CMD_PRECHARGE, &sdrc_base->cs[cs].manual);
+		writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
+		writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
+		writel(readl(&sdrc_base->cs[CS0].mr),
+			&sdrc_base->cs[CS1].mr);
 	}
 
 	/*
-- 
1.7.2.3

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Wolfgang Denk]

Dear Heiko Schocher,

In message <1287043393-2036-1-git-send-email-hs@denx.de> you wrote:
> since commit 3667cbeed5e3c4067e624e52a916b1ebb02c8f05
> on beagle board the second sdram bank didn;t longer
> work. Since this patch sdram settings just get copied
> from bank a, but CMD_NOP, CMD_PRECHARGE, CMD_AUTOREFRESH
> are not executed and after that mr register is also
> not updated. This patch adds this for the bank b.

I would like to see Steve's ACK for the original Beagle board, and
it's several versions.

Steve, what Heiko forgets to mention here is that this problem happened
on a EBV-Beagle, so there are certrain hardware differences.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
This restaurant was advertising breakfast  any  time.  So  I  ordered
french toast in the renaissance.            - Steven Wright, comedian

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Steve Sakoman]

On Thu, 2010-10-14 at 10:38 +0200, Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <1287043393-2036-1-git-send-email-hs@denx.de> you wrote:
> > since commit 3667cbeed5e3c4067e624e52a916b1ebb02c8f05
> > on beagle board the second sdram bank didn;t longer
> > work. Since this patch sdram settings just get copied
> > from bank a, but CMD_NOP, CMD_PRECHARGE, CMD_AUTOREFRESH
> > are not executed and after that mr register is also
> > not updated. This patch adds this for the bank b.
> 
> I would like to see Steve's ACK for the original Beagle board, and
> it's several versions.
> 
> Steve, what Heiko forgets to mention here is that this problem happened
> on a EBV-Beagle, so there are certrain hardware differences.

I suspect that his using an EVB-Beagle (with associated EVB x-load) is
what is causing the issue for him.

With the introduction of the Beagle xM came the need to deal with
several types of POP memory, and the resulting need for customized setup
for the SDRC.

This is best handled in x-load while running from SRAM, since timings
and mux setup are different for each memory type.

The code in Beagle x-load currently looks like this:

void config_3430sdram_ddr(void)
{
	/* reset sdrc controller */
	__raw_writel(SOFTRESET, SDRC_SYSCONFIG);
	wait_on_value(BIT0, BIT0, SDRC_STATUS, 12000000);
	__raw_writel(0, SDRC_SYSCONFIG);

	/* setup sdrc to ball mux */
	__raw_writel(SDP_SDRC_SHARING, SDRC_SHARING);

	if (beagle_revision() == REVISION_XM) {
		if (identify_xm_ddr() == MICRON_DDR) {
			__raw_writel(0x2, SDRC_CS_CFG); /* 256MB/bank */
			__raw_writel(SDP_SDRC_MDCFG_0_DDR_MICRON_XM, SDRC_MCFG_0);
			__raw_writel(SDP_SDRC_MDCFG_0_DDR_MICRON_XM, SDRC_MCFG_1);
			__raw_writel(MICRON_V_ACTIMA_200, SDRC_ACTIM_CTRLA_0);
			__raw_writel(MICRON_V_ACTIMB_200, SDRC_ACTIM_CTRLB_0);
			__raw_writel(MICRON_V_ACTIMA_200, SDRC_ACTIM_CTRLA_1);
			__raw_writel(MICRON_V_ACTIMB_200, SDRC_ACTIM_CTRLB_1);
			__raw_writel(SDP_3430_SDRC_RFR_CTRL_200MHz, SDRC_RFR_CTRL_0);
			__raw_writel(SDP_3430_SDRC_RFR_CTRL_200MHz, SDRC_RFR_CTRL_1);
		} else {
			__raw_writel(0x4, SDRC_CS_CFG); /* 512MB/bank */
			__raw_writel(SDP_SDRC_MDCFG_0_DDR_NUMONYX_XM, SDRC_MCFG_0);
			__raw_writel(SDP_SDRC_MDCFG_0_DDR_NUMONYX_XM, SDRC_MCFG_1);
			__raw_writel(NUMONYX_V_ACTIMA_165, SDRC_ACTIM_CTRLA_0);
			__raw_writel(NUMONYX_V_ACTIMB_165, SDRC_ACTIM_CTRLB_0);
			__raw_writel(NUMONYX_V_ACTIMA_165, SDRC_ACTIM_CTRLA_1);
			__raw_writel(NUMONYX_V_ACTIMB_165, SDRC_ACTIM_CTRLB_1);
			__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz, SDRC_RFR_CTRL_0);
			__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz, SDRC_RFR_CTRL_1);
		}
	} else {
		__raw_writel(0x1, SDRC_CS_CFG); /* 128MB/bank */
		__raw_writel(SDP_SDRC_MDCFG_0_DDR, SDRC_MCFG_0);
		__raw_writel(SDP_SDRC_MDCFG_0_DDR, SDRC_MCFG_1);
		__raw_writel(MICRON_V_ACTIMA_165, SDRC_ACTIM_CTRLA_0);
		__raw_writel(MICRON_V_ACTIMB_165, SDRC_ACTIM_CTRLB_0);
		__raw_writel(MICRON_V_ACTIMA_165, SDRC_ACTIM_CTRLA_1);
		__raw_writel(MICRON_V_ACTIMB_165, SDRC_ACTIM_CTRLB_1);
		__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz, SDRC_RFR_CTRL_0);
		__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz, SDRC_RFR_CTRL_1);
	}

	__raw_writel(SDP_SDRC_POWER_POP, SDRC_POWER);

	/* init sequence for mDDR/mSDR using manual commands (DDR is different) */
	__raw_writel(CMD_NOP, SDRC_MANUAL_0);
	__raw_writel(CMD_NOP, SDRC_MANUAL_1);

	delay(5000);

	__raw_writel(CMD_PRECHARGE, SDRC_MANUAL_0);
	__raw_writel(CMD_PRECHARGE, SDRC_MANUAL_1);

	__raw_writel(CMD_AUTOREFRESH, SDRC_MANUAL_0);
	__raw_writel(CMD_AUTOREFRESH, SDRC_MANUAL_1);

	__raw_writel(CMD_AUTOREFRESH, SDRC_MANUAL_0);
	__raw_writel(CMD_AUTOREFRESH, SDRC_MANUAL_1);

	/* set mr0 */
	__raw_writel(SDP_SDRC_MR_0_DDR, SDRC_MR_0);
	__raw_writel(SDP_SDRC_MR_0_DDR, SDRC_MR_1);

	/* set up dll */
	__raw_writel(SDP_SDRC_DLLAB_CTRL, SDRC_DLLA_CTRL);
	delay(0x2000);	/* give time to lock */

}

The code in u-boot to copy bank 1 settings to bank 2 was a workaround so that Beagle users
who didn't update x-load immediately would at least have a functioning system.

I don't think that Heiko's patch will do any harm and it might be a good idea so that EVB
Beagle users can use the standard Beagle u-boot.  I will have to verify that it does no
harm on all the various Beagle versions first though.

I will Ack or Nack after I do some testing.

Regards,

Steve

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Heiko Schocher]

Hello Steve,

Steve Sakoman wrote:
> On Thu, 2010-10-14 at 10:38 +0200, Wolfgang Denk wrote:
>> Dear Heiko Schocher,
>>
>> In message <1287043393-2036-1-git-send-email-hs@denx.de> you wrote:
>>> since commit 3667cbeed5e3c4067e624e52a916b1ebb02c8f05
>>> on beagle board the second sdram bank didn;t longer
>>> work. Since this patch sdram settings just get copied
>>> from bank a, but CMD_NOP, CMD_PRECHARGE, CMD_AUTOREFRESH
>>> are not executed and after that mr register is also
>>> not updated. This patch adds this for the bank b.
>> I would like to see Steve's ACK for the original Beagle board, and
>> it's several versions.
>>
>> Steve, what Heiko forgets to mention here is that this problem happened
>> on a EBV-Beagle, so there are certrain hardware differences.
> 
> I suspect that his using an EVB-Beagle (with associated EVB x-load) is
> what is causing the issue for him.

Yep, seems so.

> With the introduction of the Beagle xM came the need to deal with
> several types of POP memory, and the resulting need for customized setup
> for the SDRC.
> 
> This is best handled in x-load while running from SRAM, since timings
> and mux setup are different for each memory type.
> 
> The code in Beagle x-load currently looks like this:
[...]
> 
> The code in u-boot to copy bank 1 settings to bank 2 was a workaround so that Beagle users
> who didn't update x-load immediately would at least have a functioning system.
> 
> I don't think that Heiko's patch will do any harm and it might be a good idea so that EVB

Yep, so I think too ...

> Beagle users can use the standard Beagle u-boot.  I will have to verify that it does no
> harm on all the various Beagle versions first though.
> 
> I will Ack or Nack after I do some testing.

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Wolfgang Denk]

Dear Steve Sakoman,

In message <1287064487.7756.21.camel@quadra> you wrote:
>
> With the introduction of the Beagle xM came the need to deal with
> several types of POP memory, and the resulting need for customized setup
> for the SDRC.
> 
> This is best handled in x-load while running from SRAM, since timings
> and mux setup are different for each memory type.

I still wonder why x-load was foprked out of the U-Boot tree; I guess
a number of problems would simply not exist at all if the code was
maintained together.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Some people march to the beat of a different drummer. And some people
tango!

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Paulraj, Sandeep]

> The code in u-boot to copy bank 1 settings to bank 2 was a workaround so
> that Beagle users
> who didn't update x-load immediately would at least have a functioning
> system.
> 
> I don't think that Heiko's patch will do any harm and it might be a good
> idea so that EVB
> Beagle users can use the standard Beagle u-boot.  I will have to verify
> that it does no
> harm on all the various Beagle versions first though.
> 
> I will Ack or Nack after I do some testing.

Do let me know the results of your testing

Regards,
Sandeep

[U-Boot] [PATCH] armv7, beagle: Second SDRAM bank don;t work

[Steve Sakoman]

On Thu, Oct 14, 2010 at 1:03 AM, Heiko Schocher <hs@denx.de> wrote:
> since commit 3667cbeed5e3c4067e624e52a916b1ebb02c8f05
> on beagle board the second sdram bank didn;t longer
> work. Since this patch sdram settings just get copied
> from bank a, but CMD_NOP, CMD_PRECHARGE, CMD_AUTOREFRESH
> are not executed and after that mr register is also
> not updated. This patch adds this for the bank b.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: Steve Sakoman <steve@sakoman.com>
> cc: Sandeep Paulraj <s-paulraj@ti.com>
> cc: Wolfgang Denk <wd@denx.de>
> ---
> Wolfgang, this patch should also be added to u-boot-arm elf_reloc
>
> ?arch/arm/cpu/armv7/omap3/sdrc.c | ? ?7 +++++++
> ?1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
> index 2719bb5..3087096 100644
> --- a/arch/arm/cpu/armv7/omap3/sdrc.c
> +++ b/arch/arm/cpu/armv7/omap3/sdrc.c
> @@ -149,6 +149,13 @@ void do_sdrc_init(u32 cs, u32 early)
> ? ? ? ? ? ? ? ? ? ? ? ?&sdrc_actim_base1->ctrla);
> ? ? ? ? ? ? ? ?writel(readl(&sdrc_actim_base0->ctrlb),
> ? ? ? ? ? ? ? ? ? ? ? ?&sdrc_actim_base1->ctrlb);
> +
> + ? ? ? ? ? ? ? writel(CMD_NOP, &sdrc_base->cs[cs].manual);
> + ? ? ? ? ? ? ? writel(CMD_PRECHARGE, &sdrc_base->cs[cs].manual);
> + ? ? ? ? ? ? ? writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
> + ? ? ? ? ? ? ? writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
> + ? ? ? ? ? ? ? writel(readl(&sdrc_base->cs[CS0].mr),
> + ? ? ? ? ? ? ? ? ? ? ? &sdrc_base->cs[CS1].mr);
> ? ? ? ?}
>
> ? ? ? ?/*
> --
> 1.7.2.3

I tested this on Overos with 3 brands of POP memory and both 35XX and
37XX processors.  Seemed to do no harm on any combination, so:

Acked-by: Steve Sakoman <steve.sakoman@linaro.org>
Tested-by: Steve Sakoman <steve.sakoman@linaro.org>