All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [resent] New chapter in i.MX51 datasheet an issue?
Date: Tue, 8 May 2012 12:23:26 +0200	[thread overview]
Message-ID: <201205081223.26585.marex@denx.de> (raw)
In-Reply-To: <4FA8DD52.6090001@denx.de>

Dear Stefano Babic,

> On 07/05/2012 09:11, David Jander wrote:
> > Dear Stefano,
> 
> Hi David,
> 
> > Yes, but is none of those boards using 3.15 or 3.3V? If they are, those
> > bits must be cleared!
> 
> This is a good question - also because SD was tested and it is working
> on these cards. I am asking to myself how it can work if voltage is wrong.
> 
> >> At the moment, we have no problems and I can explain why. The only
> >> boards setting these pins (for SD card) are mx51evk and vision2. Both
> >> are setting PAD_CTL_DRV_VOT_HIGH, and because the define is wrong, they
> >> are really setting the pin to low output voltage mode.
> > 
> > AFAIK, most SD-cards need 3.1V or more to work, and the EVK boots from an
> > SD card. That means, the rails NVCC_PER15 and/or NVCC_PER17 are probably
> > powered from a 3.15 or 3.3V supply, so the HVE bits for those pins must
> > be cleared in able to avoid damage (3.3V is what they call "Ultra High
> > Voltage").
> 
> Really I have expected that SD does not work if the voltage is lower as
> specified, not that theree is a damage - I can understand this in the
> opposite case (setting high voltage when low voltage is required).
> 
> >> For other boards and other pins, voltage is not explicitely set : this
> >> means they work in low voltage mode after a reset.
> > 
> > Everyone reading the documentation as it was available before 03-2012
> > would most probably think this is ok, even for 3.1...3.6V powered pins,
> > but according to the new documentation, it isn't. So probably many
> > boards need to be re-designed or at least u-boot board-code needs to be
> > fixed for them. This is a different issue though, and needs to be
> > addressed by the different BSP maintainers or board manufacturers.
> 
> I think only u-boot code should be fixed.
> 
> >> To fix arch/arm/include/asm/arch-mx5/iomux.h and synchronize it with the
> >> documentation, we need also to change mx51evk / vision2, setting the
> >> pins to PAD_CTL_DRV_VOT_LOW, and they will work as now.
> > 
> > ... and probably die.
> 
> well, they will work as now - with low voltage instead of high voltage.
> Anyway, I agree that this should be wrong, because when the code was
> written was thought that the voltage should be high.
> 
> > The setting is most probably wrong. All we need to do,
> > is change the define in the header files, and not touch the mx51evk /
> > vision2 BSP files. But the respective maintainers need to be warned
> > IMHO.
> 
> Go ahead in this direction. Then we can test on these boards (mx51evk /
> vision2 / efikamx), the only ones having these issue).

Respective maintainer just woke up ... just send me the efika patch, I should be 
able to test ;-)

> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

  reply	other threads:[~2012-05-08 10:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 10:08 [U-Boot] [resent] New chapter in i.MX51 datasheet an issue? David Jander
2012-05-06 16:15 ` Stefano Babic
2012-05-07  7:11   ` David Jander
2012-05-08  8:46     ` Stefano Babic
2012-05-08 10:23       ` Marek Vasut [this message]
2012-05-08 12:06       ` David Jander
2012-05-08 12:51         ` Marek Vasut
2012-05-09  9:31           ` David Jander
2012-05-08 13:14         ` Stefano Babic
2012-05-09  9:36           ` David Jander
2012-05-09 10:14             ` Stefano Babic

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=201205081223.26585.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.