From: Lokesh Vutla <lokeshvutla@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
Date: Mon, 2 Dec 2013 09:51:31 +0530 [thread overview]
Message-ID: <529C0ACB.50607@ti.com> (raw)
In-Reply-To: <CANacCWyARqRd3KNUyrgF4MwdcLq_Q82utcn8bMOGJGDQJV5zSQ@mail.gmail.com>
On Thursday 28 November 2013 04:33 AM, Vaibhav Bedia wrote:
> On Wed, Nov 27, 2013 at 4:34 AM, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> [...]
>> Ideally the default value should be exported from e-fuse values.
>> EMIF does some HW sequence according to the value exported here. This filed tells
>> what type of memory it is.
>>
>
> No, eFuse is not the right place for this information. If you were to do that
> you would be restricting what memory type is supported on a particular
> device that gets shipped and that's not a scalable model.
At least this was the case for OMAPs. So it worked well..:)
>
>> I understand the point what if efuse is not blown. I am using this only after we write into sdarm_config register.
>> This can confirm that we get a correct value.
>> If this is not sufficient we can hardcode the register during startup only ?
>
> I don't see any value in writing some value in the EMIF register at one place
> and then using that here. If you already know what register values to program
> you already know the memory type.
Yes, according to the board we are passing the registers that means we know
the memory type. The same information I am getting from registers.
>
> Another place where the memory type information is needed is when the device
> enters low power state and the EMIF contents are lost. Rather than having to
> invent one more way of detecting the memory type in resume from low power state
> you could work out a persistent storage area (RTC scratchpad maybe? assuming
> the RTC is powered up) and use that in all the places. Requires some thought
> about the whole sequence but definitely doable IMHO.
We should not rely on RTC here. I don't think U-Boot should worry about low power state. You mean to
say about passing this information to kernel?
In the current kernel also memory type is derived according to the SDRAM CONFIG register only.
So I thought this would be good enough.
Thanks and regards,
Lokesh
>
>> One more thing is we can get from MR registers of DDR.
>> But for DDR3 we cannot access MR registers. That is why I didn't go with this approach.
>>
>
> So now you know why things just worked on OMAP3 (and OMAP4?) and not
> on TI81xx, AM335x and AM437x :)
>
>> Currently EEPROM doesn't have any details about DDR.
>> Please let me know if this approach is not good enough.
>>
>
> Since there's no speced way of detecting the memory type you should push for
> the right information to be made available via the EEPROM and write
> generic code.
> But hey that's for you to decide :)
>
> Regards,
> Vaibhav
>
next prev parent reply other threads:[~2013-12-02 4:21 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 6:18 [U-Boot] [PATCH V2 00/14] ARM: AM43xx: Update support for AM4372 SoC Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 01/14] ARM: AM43xx: Update the base addresses of modules Lokesh Vutla
2013-11-21 20:20 ` Vaibhav Bedia
2013-11-25 9:26 ` Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 02/14] ARM: AM43xx: Adapt to ti_armv7_common.h config file Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 03/14] ARM: AM43xx: Add L2 Support Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 04/14] ARM: AM43xx: Add extra ENV settings Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM Lokesh Vutla
2013-11-21 20:26 ` Vaibhav Bedia
2013-11-25 4:46 ` Lokesh Vutla
2013-11-26 23:49 ` Vaibhav Bedia
2013-11-21 6:18 ` [U-Boot] [PATCH V2 06/14] ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support Lokesh Vutla
2013-11-21 20:28 ` Vaibhav Bedia
2013-11-25 4:48 ` Lokesh Vutla
2013-11-26 23:51 ` Vaibhav Bedia
2013-11-21 6:18 ` [U-Boot] [PATCH V2 07/14] ARM: AM43xx: Select clk source for Timer2 Lokesh Vutla
2013-11-21 20:31 ` Vaibhav Bedia
2013-11-25 4:53 ` Lokesh Vutla
2013-11-26 23:56 ` Vaibhav Bedia
2013-11-21 6:18 ` [U-Boot] [PATCH V2 08/14] ARM: AM43xx: Update Current Booting devices list Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 09/14] ARM: AM43xx: mux: Update mux data Lokesh Vutla
2013-11-21 20:34 ` Vaibhav Bedia
2013-11-25 4:59 ` Lokesh Vutla
2013-11-26 23:58 ` Vaibhav Bedia
2013-11-21 6:18 ` [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM Lokesh Vutla
2013-11-21 20:37 ` Vaibhav Bedia
2013-11-25 5:08 ` Lokesh Vutla
2013-11-27 0:06 ` Vaibhav Bedia
2013-11-27 6:58 ` Lokesh Vutla
2013-11-27 22:48 ` Vaibhav Bedia
2013-12-02 3:53 ` Lokesh Vutla
2013-12-04 3:20 ` Vaibhav Bedia
2013-12-04 17:39 ` Sekhar Nori
2013-11-21 6:18 ` [U-Boot] [PATCH V2 11/14] ARM: AM43xx: clocks: Add DPLL data for GP EVM Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2 Lokesh Vutla
2013-11-21 20:46 ` Vaibhav Bedia
2013-11-25 5:13 ` Lokesh Vutla
2013-11-27 0:12 ` Vaibhav Bedia
2013-11-27 4:48 ` Lokesh Vutla
2013-11-21 6:18 ` [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3 Lokesh Vutla
2013-11-21 20:52 ` Vaibhav Bedia
2013-11-25 5:18 ` Lokesh Vutla
2013-11-27 0:17 ` Vaibhav Bedia
2013-11-27 9:34 ` Lokesh Vutla
2013-11-27 23:03 ` Vaibhav Bedia
2013-12-02 4:21 ` Lokesh Vutla [this message]
2013-12-04 3:24 ` Vaibhav Bedia
2013-11-21 6:18 ` [U-Boot] [PATCH V2 14/14] ARM: AM43xx: Add Maintainer Lokesh Vutla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529C0ACB.50607@ti.com \
--to=lokeshvutla@ti.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.