[U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Tom Rini]

On Wed, Nov 13, 2013 at 12:50:50PM -0500, Vaibhav Bedia wrote:
> Hi Sekhar :)
> 
> On Wed, Nov 13, 2013 at 11:08 AM, Sekhar Nori <nsekhar at ti.com> wrote:
> > Hi Vaibhav,
> >
> > On 11/13/2013 7:38 PM, Vaibhav Bedia wrote:
> >> On Wed, Nov 13, 2013 at 3:48 AM, Lokesh Vutla <lokeshvutla at ti.com> wrote:
> >> [...]
> >>> I checked with hardware folks. There is no register or some way to tell
> >>> if VTT is present. It is not added in EEPROM also and I have no answer why it
> >>> is not added in EEPROM..:(
> >>> It is specific to boards using DDR3. So its good to have it in board files as I did it here
> >>> instead of adding this check in emif file.
> >>
> >> That EEPROM is clearly not getting used the way i think it should be :\
> >> I would have made a lot of noise to get details like this added there.
> >
> > The EEPROM was designed as a way to differentiate between different TI
> > EVMs, not as a generic way to differentiate between various possible
> > board hook-ups. Even if we did define it that way, why would all boards
> > using AM437x have an onboard EEPROM?
> >
> > We could request this information be placed in EEPROM and see if
> > hardware folks oblige, but I don't see how that's going to be used
> > beyond TI EVMs.
> >
> 
> I understand the intent of customers to get rid of all the components
> they can to lower the cost. But if one just thinks about this a bit more,
> the current solution does a half-hearted attempt to differentiate the boards
> variants. It doesn't really capture the differences that are there and that
> is leading to hard coding to a certain extent.
> 
> From AM335x boards we should now have a decent idea of what
> things change across boards that go into production. I don't think it
> makes sense to throw away all that knowledge and go ahead
> assuming we will never make a change. The request for change is just
> to future proof the current code and have the EEPROM actually help us
> do our jobs. Why? Because life's too short to keep worrying about why a
> board rev that a you pick up from a neighbor's desk doesn't boot, hooking
> up the JTAG to trace the DDR setup code, figure out what needs to change
> in the boot-loader, add in the appropriate check and then get to the task
> at hand ;)

In theory, one could also learn from the customers that did keep the
EEPROM about what additional information they programmed in.

I think however, the most likely outcome here is that we'll be able to
only rely on the board name (and rev) part of the EEPROM being populated
and the board code should be clear and well commented about non-obvious
things such as design choice A means B is required.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/e91a24ce/attachment.pgp>