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

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

[David Jander]

Hi all,

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

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?

Best regards,

-- 
David Jander
Protonic Holland.

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

[Stefano Babic]

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.

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

For other boards and other pins, voltage is not explicitely set : this
means they work in low voltage mode after a reset.

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.

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

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

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

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

Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[Marek Vasut]

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

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

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

[Marek Vasut]

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

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

[David Jander]

On Tue, 8 May 2012 14:51:52 +0200
Marek Vasut <marex@denx.de> wrote:

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

Why do you think that?
ESD protection is not something that could possibly have something to do with
a running board and wrong PAD configuration bit settings. Or do you mean that
IO-pad ESD protection is the thing that gets destroyed by wrong settings?

AFAICS, this bit probably enables and disables a different set of output
transistors on the pad.

Whether damage is likely to happen or not, is not clear to me yet. I am waiting
on a reply from Freescale about this issue right now. I will post any important
findings here as soon as I know more.

Best regards,

-- 
David Jander
Protonic Holland.

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

[Stefano Babic]

On 08/05/2012 14:06, David Jander wrote:

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

What we can do is to change all MX51 boards in mainline (the three
boards we have already mentioned), explaining in the commit-id of the
patch why we change. We do not care about boards that were not pushed to
mainline.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[David Jander]

On Tue, 08 May 2012 15:14:47 +0200
Stefano Babic <sbabic@denx.de> wrote:

> On 08/05/2012 14:06, David Jander wrote:
> 
> >> 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.
> 
> What we can do is to change all MX51 boards in mainline (the three
> boards we have already mentioned), explaining in the commit-id of the
> patch why we change. We do not care about boards that were not pushed to
> mainline.

Seems reasonable. Are you also implying that you are willing to propose a
patch? (Swapping the two values seems fairly trivial....)

Best regards,

-- 
David Jander
Protonic Holland.

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

[Stefano Babic]

On 09/05/2012 11:36, David Jander wrote:

> Seems reasonable. Are you also implying that you are willing to propose a
> patch? (Swapping the two values seems fairly trivial....)

Patch is coming

Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================