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

[David Jander]

On Tue, 08 May 2012 10:46:10 +0200
Stefano Babic <sbabic at 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.....

> >> 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,

-- 
David Jander
Protonic Holland.