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

[David Jander]

Dear Stefano,

On Sun, 06 May 2012 18:15:18 +0200
Stefano Babic <sbabic at denx.de> wrote:

> On 04/05/2012 12:08, David Jander wrote:
> > 
> > Hi all,
> > 
> 
> Hi David,
> 
> > I discovered a bug in u-boot, that got evident after Freescale updated the
> > i.MX51 datasheets to revision 5 in March this year. I don't know if it is a
> > serious problem or not, but if I believe the wording of the datasheet many of
> > the boards that use a i.MX51 processor and running u-boot as of latest git,
> > can potentially suffer "permanent damage", whatever that means.
> > 
> > I am referring to the new paragraphs at the end of chapter 4.3.4 of the
> > datasheet, and the wrong interpretation of the meaning of the HVE bit in the
> > iomuxc.h header file of u-boot here:
> > 
> > arch/arm/include/asm/arch-mx5/iomux.h:
> > 
> > ...
> >   69         PAD_CTL_DRV_VOT_LOW = 0x0 << 13, /* Low voltage mode */
> >   70         PAD_CTL_DRV_VOT_HIGH = 0x1 << 13,/* High voltage mode */
> > ...
> > 
> 
> Agree. The header defines the bit wrongly.
> 
> It seems to me that the Reference Manual is correct. It is from
> 24/2/2010 and it was not updated.
> 
> After a reset, value is set to 1, and this means low-voltage for the
> most pins.

Yes, but is none of those boards using 3.15 or 3.3V? If they are, those bits
must be cleared!

> > According to the reference manual, the correct meaning of this bit is negated:
> > 
> > "Bit 13:
> > High / Low Output Voltage Range. This bit selects the output voltage mode for
> > SD2_CMD. 0 High output voltage mode
> > 1 Low output voltage mode"
> > 
> > Added to the new paragraph in the datasheet:
> > 
> > "The UHVIO type of I/O cells have to be configured properly according to their
> > supply voltage level, in order to prevent permanent damage to them and in
> > order to not degrade their timing performance."
> > 
> > Seems like we may have a problem here!
> > 
> > I would like to know if anyone is aware of this? Does anyone know of a board
> > that is actually destroyed this way?
> 
> 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").

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

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

> We can also drop completely PAD_CTL_DRV_VOT_HIGH from these two boards
> and use the reset value.

PAD_CTL_DRV_VOT_HIGH should be a NOP in a bit mask, since its value should be
0.
PAD_CTL_DRV_VOT_LOW should be 1. Board code most probably shouldn't be
changed, because it most probably assumes that the "meaning" of the define is
right, and not its value.

Best regards,

-- 
David Jander
Protonic Holland.