[U-Boot] [resent] New chapter in i.MX51 datasheet an issue?

[Marek Vasut <marex@denx.de>]

Dear David Jander,

> On Tue, 08 May 2012 10:46:10 +0200
> 
> Stefano Babic <sbabic@denx.de> wrote:
> > 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.
> 
> That is the whole point: You probably won't notice anything with the wrong
> settings.... besides slightly lower drive-strength on the pin. Things
> should just work with either setting. The problem is that now Freescale is
> telling us that using the incorrect settings can cause "permanent damage"
> to the chip!!! No idea what sort of damage nor whether it occurs
> frequently.....

I think it might have something to do with ESD. It's probably unlikely to happen 
anyway.

> > >> 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).
> 
> The setting doesn't affect the actual output voltage or something like
> that. This bit only changes some electrical characteristics of the PAD-IO
> circuitry, in order to perform better for lower or for higher rail
> power... depending on its value. Apparently Freescale now discovered that
> its not only affecting minor timing details that probably are irrelevant
> for most uses, but also that the chip can malfunction ("permanent damage
> can occur").
> 
> > >> 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.
> 
> Potentially also board code, in the cases where the settings are not
> matching the actual hardware.... not because it doesn't work, but rather
> to avoid possible "permanent damage". That's something board designers/BSP
> maintainers should care about.
> 
> > >> 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.
> 
> See above.
> 
> > > 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).
> 
> I agree we should only change the headers, but... if there are more i.MX51
> boards, they may all potentially need to fix their board code.... and that
> is up to them. Unfortunately this warning/wake-up call should come from
> Freescale themselves, but I have not heared anything from them.
> 
> Best regards,

Best regards,
Marek Vasut