Aneesh,
looping in x-loader list as well (apologies if cross posting is discouraged in linaro list)..

x-loader list - fyi..
Aneesh V wrote, on 02/08/2011 06:53 PM:
Hi Andy,

On Tuesday 08 February 2011 03:11 PM, Andy Green wrote:
From: Andy Green<andy.gr...@linaro.org>

When the OMAP 4 on Panda sees that USB OTG external power is present,
it changes the boot flow in the ROM to try to boot via that before
trying MMC1. If it isn't satisfied, it falls through to try MMC1.

Without this patch, under those conditions X-Loader is unable to
update the DPLL as it needs to do during dram initialization, because
the EMIF never goes idle allowing the shadow update mechanism to
apply the new settings.

There is a specific requirement that MEMIF clock domain should be in SW
wakeup mode during this FREQ_UPDATE procedure. It can not be in HW_AUTO
either. However, after the sequence it's better to put it in HW_AUTO.
This is the recommended sequence. I found this in our functional spec.
I am not sure if this is available in the public TRM though.

Would you please take a look at this patch in our internal tree.
It seems to be fixing the same issue. I faced exactly same problem on
Blaze.

http://dev.omapzoom.org/?p=bootloader/x-loader.git;a=commit;h=7ecbec096c300c7e71b663eae51945522329bfbd


Unfortunately the mainline x-loader doesn't seem to have this fix.


It therefore loops for a long period waiting to confirm the settings
applied and boot is hung (with LEDs off, so the device looks OFF).

This patch re-enables EMIF idle which was previously commented out with
"No IDLE: BUG in SDC" to allow the new DPLL settings to apply.

With the patch against http://gitorious.org/x-loader HEAD the Panda is
able to boot from either USB OTG power applied or DC Jack power OK.

Note that I saw peak current during boot of 650mA, higher than the
500mA allowed by USB. It may go higher with other peripherals enabled
or trying to use USB host on Panda.

Cc: Menon Nishanth<menon.nisha...@gmail.com>
Signed-off-by: Andy Green<a...@warmcat.com>
---

board/omap4430panda/clock.c | 6 +++++
board/omap4430panda/omap4430panda.c | 46
+++++++++++++++++++++++++++++++++--
2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/board/omap4430panda/clock.c b/board/omap4430panda/clock.c
index a83f1c6..c75dff7 100644
--- a/board/omap4430panda/clock.c
+++ b/board/omap4430panda/clock.c
@@ -538,6 +538,12 @@ void lock_core_dpll_shadow(void)
*/
*(volatile int*)0x4A004260 = 0x70D | (dpll_param_p->m2<< 11);

+ /*
+ * if the EMIF never goes idle, and eg, if ROM enabled USB,
+ * we loop for a very very long time here becuse shadow updates wait
+ * until EMIF idle
+ */
+
/* Wait for Freq_Update to get cleared: CM_SHADOW_FREQ_CONFIG1 */
while( ( (*(volatile int*)0x4A004260)& 0x1) == 0x1 );


I think it will be better to put the MEMIF clock domain back in HW_AUTO
mode after this.

diff --git a/board/omap4430panda/omap4430panda.c
b/board/omap4430panda/omap4430panda.c
index a91e2aa..c2fd1f9 100644
--- a/board/omap4430panda/omap4430panda.c
+++ b/board/omap4430panda/omap4430panda.c
@@ -417,9 +417,21 @@ static void ddr_init(void)
*/
configure_core_dpll_no_lock();

+ /*
+ * the following is re-enabled because without the EMIF going idle,
+ * the shadow DPLL update scheme can delay for minutes until it is
+ * able to apply the new settings... it waits until EMIF idle.
+ *
+ * This is seen in the case the ROM enabled USB boot being tried before
+ * normal boot over MMC.
+ */
+
+#if 1
/* No IDLE: BUG in SDC */
- //sr32(CM_MEMIF_CLKSTCTRL, 0, 32, 0x2);
- //while(((*(volatile int*)CM_MEMIF_CLKSTCTRL)& 0x700) != 0x700);
+ sr32(CM_MEMIF_CLKSTCTRL, 0, 32, 0x2);
+ while(((*(volatile int*)CM_MEMIF_CLKSTCTRL)& 0x700) != 0x700);
+#endif
+
*(volatile int*)(EMIF1_BASE + EMIF_PWR_MGMT_CTRL) = 0x0;
*(volatile int*)(EMIF2_BASE + EMIF_PWR_MGMT_CTRL) = 0x0;

@@ -623,7 +635,14 @@ void s_init(void)
{
unsigned int rev = omap_revision();

+ /*
+ * this is required to survive the muxconf in the case the ROM
+ * started up USB OTG
+ */
+ prcm_init();

Are you doing prcm_init() two times. Isn't that unnecessary? Perhaps
you could avoid the second one?

+
set_muxconf_regs();
+
delay(100);

/* Writing to AuxCR in U-boot using SMI for GP/EMU DEV */
@@ -637,7 +656,7 @@ void s_init(void)
/* Set VCORE1 = 1.3 V, VCORE2 = VCORE3 = 1.21V */
#if defined(CONFIG_MPU_600) || defined(CONFIG_MPU_1000)
scale_vcores();
-#endif
+#endif
prcm_init();

if(rev != OMAP4430_ES1_0) {
@@ -1203,7 +1222,28 @@ int dram_init(void)
*********************************************************/
void set_muxconf_regs(void)
{
+ unsigned int v;
+
MUX_DEFAULT_OMAP4();
+
+ /*
+ * If the ROM has started the OTG stuff, stop it and
+ * make it look as if uninitialized
+ */
+
+ /* hold OTG phy in reset */
+
+ v = __raw_readl(O4_GPIO_BASE2 + 0x134);
+ __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x134);
+
+ v = __raw_readl(O4_GPIO_BASE2 + 0x13c);
+ __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x13c);
+
+ /* kill USB PLL */
+
+ v = __raw_readl(0x4a008100 + 0x80);
+ __raw_writel((v& ~(7<< 0)) | 1, 0x4a008100 + 0x80);

Should this go in a different function?

+
return;
}


Best regards,
Aneesh



--
Regards,
Nishanth Menon

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to