Dear David Jander, > On Tue, 08 May 2012 10:46:10 +0200 > > Stefano Babic <sba...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot