[U-Boot] i.MX28: Fix VDDIO and VDDA setup

The DC power STS shouldn't be checked if booting off 5V supply.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Robert Deliën <robert@delien.nl>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
---
 arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

Note: Guys, please give this a testrun. I think it might fix the issue Robert
was observing. I dug into the imx-bootlets and the bootrom X-Files and found
this paranormal piece of code. Adding it fixes the boot issue on my crappy
board.

M

I tested both patch on my mx28evk. At least I cannot notice any
missbehavior :-) Downloading the patched u-boot via USB recovery
download still does not work.

Marek, did you find any further mentionable difference between bootlets
code and current u-boot implementation?

Matthias

On 31.01.2012 01:00, Marek Vasut wrote:
> The DC power STS shouldn't be checked if booting off 5V supply.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Robert Deliën <robert@delien.nl>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
> ---
>  arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   16 ++++++++++++----
>  1 files changed, 12 insertions(+), 4 deletions(-)
> 
> Note: Guys, please give this a testrun. I think it might fix the issue Robert
> was observing. I dug into the imx-bootlets and the bootrom X-Files and found
> this paranormal piece of code. Adding it fixes the boot issue on my crappy
> board.
> 
> M
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> index ee0f237..c6c25d9 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> @@ -802,7 +802,9 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t new_brownout)
>  			clrsetbits_le32(&power_regs->hw_power_vddioctrl,
>  				POWER_VDDIOCTRL_TRG_MASK, diff);
>  
> -			if (powered_by_linreg)
> +			if (powered_by_linreg ||
> +				(readl(&power_regs->hw_power_sts) &
> +					POWER_STS_VDD5V_GT_VDDIO))
>  				early_delay(1500);
>  			else {
>  				while (!(readl(&power_regs->hw_power_sts) &
> @@ -837,7 +839,9 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t new_brownout)
>  			clrsetbits_le32(&power_regs->hw_power_vddioctrl,
>  				POWER_VDDIOCTRL_TRG_MASK, diff);
>  
> -			if (powered_by_linreg)
> +			if (powered_by_linreg ||
> +				(readl(&power_regs->hw_power_sts) &
> +					POWER_STS_VDD5V_GT_VDDIO))
>  				early_delay(1500);
>  			else {
>  				while (!(readl(&power_regs->hw_power_sts) &
> @@ -895,7 +899,9 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
>  			clrsetbits_le32(&power_regs->hw_power_vdddctrl,
>  				POWER_VDDDCTRL_TRG_MASK, diff);
>  
> -			if (powered_by_linreg)
> +			if (powered_by_linreg ||
> +				(readl(&power_regs->hw_power_sts) &
> +					POWER_STS_VDD5V_GT_VDDIO))
>  				early_delay(1500);
>  			else {
>  				while (!(readl(&power_regs->hw_power_sts) &
> @@ -930,7 +936,9 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
>  			clrsetbits_le32(&power_regs->hw_power_vdddctrl,
>  					POWER_VDDDCTRL_TRG_MASK, diff);
>  
> -			if (powered_by_linreg)
> +			if (powered_by_linreg ||
> +				(readl(&power_regs->hw_power_sts) &
> +					POWER_STS_VDD5V_GT_VDDIO))
>  				early_delay(1500);
>  			else {
>  				while (!(readl(&power_regs->hw_power_sts) &

> I tested both patch on my mx28evk. At least I cannot notice any
> missbehavior :-) Downloading the patched u-boot via USB recovery
> download still does not work.

Good, any improvements though?
> 
> Marek, did you find any further mentionable difference between bootlets
> code and current u-boot implementation?

Not yet.
> 
> Matthias

M
> 
> On 31.01.2012 01:00, Marek Vasut wrote:
> > The DC power STS shouldn't be checked if booting off 5V supply.
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Robert Deliën <robert@delien.nl>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
> > ---
> > 
> >  arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   16 ++++++++++++----
> >  1 files changed, 12 insertions(+), 4 deletions(-)
> > 
> > Note: Guys, please give this a testrun. I think it might fix the issue
> > Robert was observing. I dug into the imx-bootlets and the bootrom
> > X-Files and found this paranormal piece of code. Adding it fixes the
> > boot issue on my crappy board.
> > 
> > M
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> > b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c index ee0f237..c6c25d9
> > 100644
> > --- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> > @@ -802,7 +802,9 @@ void mx28_power_set_vddio(uint32_t new_target,
> > uint32_t new_brownout)
> > 
> >  			clrsetbits_le32(&power_regs->hw_power_vddioctrl,
> >  			
> >  				POWER_VDDIOCTRL_TRG_MASK, diff);
> > 
> > -			if (powered_by_linreg)
> > +			if (powered_by_linreg ||
> > +				(readl(&power_regs->hw_power_sts) &
> > +					POWER_STS_VDD5V_GT_VDDIO))
> > 
> >  				early_delay(1500);
> >  			
> >  			else {
> >  			
> >  				while (!(readl(&power_regs->hw_power_sts) &
> > 
> > @@ -837,7 +839,9 @@ void mx28_power_set_vddio(uint32_t new_target,
> > uint32_t new_brownout)
> > 
> >  			clrsetbits_le32(&power_regs->hw_power_vddioctrl,
> >  			
> >  				POWER_VDDIOCTRL_TRG_MASK, diff);
> > 
> > -			if (powered_by_linreg)
> > +			if (powered_by_linreg ||
> > +				(readl(&power_regs->hw_power_sts) &
> > +					POWER_STS_VDD5V_GT_VDDIO))
> > 
> >  				early_delay(1500);
> >  			
> >  			else {
> >  			
> >  				while (!(readl(&power_regs->hw_power_sts) &
> > 
> > @@ -895,7 +899,9 @@ void mx28_power_set_vddd(uint32_t new_target,
> > uint32_t new_brownout)
> > 
> >  			clrsetbits_le32(&power_regs->hw_power_vdddctrl,
> >  			
> >  				POWER_VDDDCTRL_TRG_MASK, diff);
> > 
> > -			if (powered_by_linreg)
> > +			if (powered_by_linreg ||
> > +				(readl(&power_regs->hw_power_sts) &
> > +					POWER_STS_VDD5V_GT_VDDIO))
> > 
> >  				early_delay(1500);
> >  			
> >  			else {
> >  			
> >  				while (!(readl(&power_regs->hw_power_sts) &
> > 
> > @@ -930,7 +936,9 @@ void mx28_power_set_vddd(uint32_t new_target,
> > uint32_t new_brownout)
> > 
> >  			clrsetbits_le32(&power_regs->hw_power_vdddctrl,
> >  			
> >  					POWER_VDDDCTRL_TRG_MASK, diff);
> > 
> > -			if (powered_by_linreg)
> > +			if (powered_by_linreg ||
> > +				(readl(&power_regs->hw_power_sts) &
> > +					POWER_STS_VDD5V_GT_VDDIO))
> > 
> >  				early_delay(1500);
> >  			
> >  			else {
> >  			
> >  				while (!(readl(&power_regs->hw_power_sts) &

On 1/30/12, Marek Vasut <marek.vasut@gmail.com> wrote:

> Note: Guys, please give this a testrun. I think it might fix the issue
> Robert
> was observing. I dug into the imx-bootlets and the bootrom X-Files and found
> this paranormal piece of code. Adding it fixes the boot issue on my crappy
> board.

Tried your patch and my mx28evk still hangs after a "reboot" command.
It reads the scratch registers as 0, report the total RAM size as 0
and then U-boot hangs.

Regards,

Fabio Estevam

> On 1/30/12, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Note: Guys, please give this a testrun. I think it might fix the issue
> > Robert
> > was observing. I dug into the imx-bootlets and the bootrom X-Files and
> > found this paranormal piece of code. Adding it fixes the boot issue on
> > my crappy board.
> 
> Tried your patch and my mx28evk still hangs after a "reboot" command.
> It reads the scratch registers as 0, report the total RAM size as 0
> and then U-boot hangs.

Right, because RAM size is 0. I see, so DRAM init fails somewhere. I think 
though it doesn't hang in the POWER init code anymore. Can you trace mem_init() 
in the SPL? Simply define CONFIG_SPL_SERIAL_SUPPORT for example and run 
serial_init() before, then run serial_puts() every now and then when fit.

M

> 
> Regards,
> 
> Fabio Estevam

On 31.01.2012 12:38, Marek Vasut wrote:
>> I tested both patch on my mx28evk. At least I cannot notice any
>> missbehavior :-) Downloading the patched u-boot via USB recovery
>> download still does not work.
> 
> Good, any improvements though?
No. It works as before. Whatever that means :-)
I will respond to my prior USB posting with some news about that.

Matthias

Hi,

Same here. I've applied the patch and tried it on my mx28evk and 'reboot' from the
Kernel prompt results into DRAM: 0 Bytes and a hanging U-Boot.

I didn't try single-stepping with the debugger yet; I'm still messing around
with the PLL bypass bit and PLL configuration.

Cheers,

        Robert.

> Right, because RAM size is 0. I see, so DRAM init fails somewhere.

That's exactly where and why it hangs, in my case.

> I think
> though it doesn't hang in the POWER init code anymore.

In my case, I don't think it hung in power_init before your patch. I'm pretty sure it
hung at the same place.

> Can you trace mem_init()
> in the SPL? Simply define CONFIG_SPL_SERIAL_SUPPORT for example and run
> serial_init() before, then run serial_puts() every now and then when fit.

I'm trying too. I'm also trying to figure out the call stack of mx28_dram_init(), but no luck
so far.

> > Right, because RAM size is 0. I see, so DRAM init fails somewhere.
> 
> That's exactly where and why it hangs, in my case.
> 
> > I think
> > though it doesn't hang in the POWER init code anymore.
> 
> In my case, I don't think it hung in power_init before your patch. I'm
> pretty sure it hung at the same place.
> 
> > Can you trace mem_init()
> > in the SPL? Simply define CONFIG_SPL_SERIAL_SUPPORT for example and run
> > serial_init() before, then run serial_puts() every now and then when fit.
> 
> I'm trying too. I'm also trying to figure out the call stack of
> mx28_dram_init(), but no luck so far.

Try s/0x2a/~(26)/ in spl_mem_init.c ... to lower the freq to 166MHz and see what 
it does.

M

> > Right, because RAM size is 0. I see, so DRAM init fails somewhere.
> 
> That's exactly where and why it hangs, in my case.
> 
> > I think
> > though it doesn't hang in the POWER init code anymore.
> 
> In my case, I don't think it hung in power_init before your patch. I'm
> pretty sure it hung at the same place.
> 
> > Can you trace mem_init()
> > in the SPL? Simply define CONFIG_SPL_SERIAL_SUPPORT for example and run
> > serial_init() before, then run serial_puts() every now and then when fit.
> 
> I'm trying too. I'm also trying to figure out the call stack of
> mx28_dram_init(), but no luck so far.

Ok, what happens if you replace mx28_dram_init() with:

while (!readl(0x8001c280))
	mx28_mem_init();

?

> Ok, what happens if you replace mx28_dram_init() with:
> 
> while (!readl(0x8001c280))
> 	mx28_mem_init();

I'm sorry for my late response; I was attending an FPGA workshop today. I will
test this first thing in the morning, when I'm at the office.

Hi Marek,

> Ok, what happens if you replace mx28_dram_init() with:
> 
> while (!readl(0x8001c280))
>        mx28_mem_init();

It's not entirely clear what you'd like me to try: mx28_dram_init
is called in U-Boot, while mx28_mem_init is SPL code.
I have tried to link SPL objects along, but I'm getting a number
of duplicate symbols now. Before I start fixing that, I'd first
like to know if that's really what you want me to try.

On 31/01/2012 01:00, Marek Vasut wrote:
> The DC power STS shouldn't be checked if booting off 5V supply.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Robert Deliën <robert@delien.nl>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
> ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic