Message ID | 1327968001-13567-1-git-send-email-marek.vasut@gmail.com |
---|---|
State | Accepted |
Commit | 534dbd12197e2f40aeb29814686daf39a75d1eae |
Delegated to: | Stefano Babic |
Headers | show |
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
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) &
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