From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mx23: Put back RAM voltage level to its original value
Date: Fri, 26 Apr 2013 23:07:57 +0200 [thread overview]
Message-ID: <201304262307.57180.marex@denx.de> (raw)
In-Reply-To: <CAOMZO5DXXYM1+trZoMZWDP5foeKTe3WJZ5ytMCCuW-u9hfvGSw@mail.gmail.com>
Dear Fabio Estevam,
> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> > http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg
> > check this, this is as much as I got from tsvetan so far, it's the
> > VDDMEM ramping. I dunno what's that weird drop before it starts going
> > from 1V5 to 2V5, but it's strange at best and I don't like it. I think
> > that's also the source of our problems, the DRAM suffers undervolt and
> > quickly afterwards is configured for regular operation ... I'd say check
> > mx23_mem_setup_vddmem() and inspect the
>
> Currently mx23_mem_setup_vddmem() does not clear ENABLE_ILIMIT
> bit as recommended by the mx23 Reference Manual:
>
> "Controls the inrush limit (~10mA) for the memory
> supply voltage. Default is active. This should remain
> active until the supply settles after enabling the linreg.
> This should be disabled before accessing the memory."
>
> FSL bootlets does clear this bit.
>
> I did the same as FSL bootlets locally and this alone does not allowed
> me to boot the kernel without bumping VDDMEM to 2.6V.
>
> I can send a patch that clears ENABLE_LIMIT, after this one gets applied.
Fabio, can you get someone in FSL to measure all these VDDx (VDDD, VDDA, VDDIO,
VDDMEM) rails with stock 2013.04 U-Boot image from powerup to u-boot command
line and send us the results? You'd need a scope that can produce an image of
what's happening on the rails. I just can't figure out how to get this displayed
on my scope, sorry :-(
Best regards,
Marek Vasut
next prev parent reply other threads:[~2013-04-26 21:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-26 16:01 [U-Boot] [PATCH] mx23: Put back RAM voltage level to its original value Fabio Estevam
2013-04-26 16:20 ` Marek Vasut
2013-04-26 17:14 ` Fabio Estevam
2013-04-26 18:21 ` Marek Vasut
2013-04-26 21:08 ` Fabio Estevam
2013-04-26 21:11 ` Marek Vasut
2013-04-26 16:24 ` Eric Bénard
2013-04-26 17:17 ` Fabio Estevam
2013-04-26 18:16 ` Marek Vasut
2013-04-26 19:42 ` Eric Bénard
2013-04-26 20:08 ` Fabio Estevam
2013-04-26 20:13 ` Otavio Salvador
2013-04-26 20:58 ` Marek Vasut
2013-04-26 23:01 ` Otavio Salvador
2013-04-26 23:33 ` Marek Vasut
2013-04-27 11:09 ` Stefano Babic
2013-04-27 11:34 ` Marek Vasut
2013-04-27 17:28 ` Fabio Estevam
2013-04-27 17:53 ` Otavio Salvador
2013-04-27 18:39 ` Marek Vasut
2013-04-26 20:56 ` Marek Vasut
2013-04-26 21:10 ` Fabio Estevam
2013-04-26 21:14 ` Marek Vasut
2013-04-26 20:58 ` Fabio Estevam
2013-04-26 21:07 ` Marek Vasut [this message]
2013-04-26 18:14 ` Robert Nelson
2013-04-28 9:06 ` Stefano Babic
2013-04-28 23:06 ` Marek Vasut
2013-04-28 23:19 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201304262307.57180.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox