Re: [U-Boot] [PATCH 4/5] board: ti: am43xx: add AM437x SK PHY Address
Hi Felipe,
On Jun 10, 2014 11:45 AM, Felipe Balbi ba...@ti.com wrote:
pass correct PHY Address when running on SK
so that we have working ethernet with this board
too.
Signed-off-by: Felipe Balbi ba...@ti.com
---
board/ti/am43xx/board.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index b184c20..054a452 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -227,16 +227,16 @@ static const struct emif_regs
ddr3_sk_emif_regs_400Mhz = {
.read_idle_ctrl = 0x0005,
.zq_config = 0x50074be4,
.temp_alert_config = 0x0,
- .emif_ddr_phy_ctlr_1= 0x0e084007,
+ .emif_ddr_phy_ctlr_1= 0x0e084008,
.emif_ddr_ext_phy_ctrl_1= 0x08020080,
- .emif_ddr_ext_phy_ctrl_2= 0x00700070,
- .emif_ddr_ext_phy_ctrl_3= 0x00700070,
- .emif_ddr_ext_phy_ctrl_4= 0x00700070,
- .emif_ddr_ext_phy_ctrl_5= 0x00700070,
+ .emif_ddr_ext_phy_ctrl_2= 0x89,
+ .emif_ddr_ext_phy_ctrl_3= 0x90,
+ .emif_ddr_ext_phy_ctrl_4= 0x8e,
+ .emif_ddr_ext_phy_ctrl_5= 0x8d,
.emif_rd_wr_lvl_rmp_win = 0x0,
- .emif_rd_wr_lvl_rmp_ctl = 0x0,
- .emif_rd_wr_lvl_ctl = 0x0,
- .emif_rd_wr_exec_thresh = 0x0405
+ .emif_rd_wr_lvl_rmp_ctl = 0x,
+ .emif_rd_wr_lvl_ctl = 0x,
+ .emif_rd_wr_exec_thresh = 0x,
};
Merge this hunk with the previous patch in the series?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 00/14] ARM: AM43xx: Update support for AM4372 SoC
Hi Lokesh, On Tue, Dec 10, 2013 at 4:32 AM, Lokesh Vutla lokeshvu...@ti.com wrote: This Patch series updates support for AM4372 EPOS and GP EVM boards. AM4372 is a low cost Cortex-A9 based application processor targeted at existing ARM9/ARM11 base of customers that need more processing capabilities. Currently there are two boards with AM4372 SoC: EPOS and GP EVM. Except for few differences like oscillator clock and SDRAM both EPOS and GP EVM boards are similar. EPOS EVM: OSC clk : 25MHz DDR : LPDDR2 @ 266MHz (MT42L256M32D2LG-25 WT:A) GP EVM: OSC clk : 24MHz DDR : DDR3 @ 400MHz(MT41K512M8RH) This patch series is applied on top of Mainline U-Boot Tree and two patches mentioned below: git://git.denx.de/u-boot.git master http://patchwork.ozlabs.org/patch/288175/ This series looks good to me. So FWIW Reviewed-by: Vaibhav Bedia vaibhav.be...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM
On Sun, Dec 1, 2013 at 10:53 PM, Lokesh Vutla lokeshvu...@ti.com wrote: [...] I read more about it and got inputs from Sekhar. I came to know that there is a DEV_ATTRIBUTE register which tells about the safest OPP to boot with. Looks like this should be sufficient to get the values. Ill add this code and update the patch. Hmm i don't know how that field gets populated. Unless it's coming from the eFuse i really doubt it would serve the purpose. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Sun, Dec 1, 2013 at 11:21 PM, Lokesh Vutla lokeshvu...@ti.com wrote: ][...] 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? No. I am not asking you to pass this to the 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. The only problem with this being that register is also lost when you go lower than DeepSleep and would require you to figure out how to get the memory type. Your call though. I guess i am just trying to over-engineer things ;) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM
On Wed, Nov 27, 2013 at 1:58 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Wednesday 27 November 2013 05:36 AM, Vaibhav Bedia wrote: On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote: On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM. Following are the DPLL locking frequencies at OPP NOM: MPU locks at 600MHz Core locks at 1000MHz Per locks at 960MHz DDR locks at 266MHz As mentioned earlier, this hardcoded frequency approach is really not scalable when you have more device variants coming in. Just look at the AM335x changes on how this gets complicated. We already had a discussion on this during V1 of this series. Sekhar and Tom replied to you comments. What is the point in asking the same question again? Because i don't recall any conclusion being reached on that thread? Because the objective of a patch review is to come up with a solution which learns from the past and doesn't try to brush the past issues under the carpet under the assumption that the shiny new device will never have bugs? Yes I agree with you point. But I have replied to this thread saying that Currently these values are not blown in eFuse. Both EPOS and GP evms support OPP NOM. So there is no harm in booting at OPP NOM here. You haven't come back on that. Sorry i somehow missed replying to that. So here's the thing. Right now you are told that all the devices support OPP NOM and hence as the U-Boot maintainer for AM437x you go ahead and use that information. However, few days down the line you'll have different speed grades coming out of the fab and some of them are going to have a max OPP that's lower than what OPP_NOM means. After a few devices blow up and some mails go around the world your code gets blamed and you hastily come up with a patch which tries to address the slower devices. The future you then realizes that you need some mechanism the differentiate the old devices without the eFuse information and the new which do. You might discover that there's some board rev check or something like that can be used. But that's only if you are lucky. I hope you see where this is going. So what can you do? A. Go ahead with OPP NOM and be prepared to debug boot failures on random boards only to discover that the devices are not meant to operate at OPP_NOM. B. Find the lowest common denominator for the supported OPPs and use that in here. This might end up making some folks unhappy but then you need to make a choice between fast and reliable and i would personally go for the latter. If folks really care about boot times someone needs to start putting the right information in the eFuses at the right time. Since you are very concerned here. Why are you feeling it so complicated when new variants come? We can always differentiate the new variant from the old ones and can pass dpll structure accordingly. It is just a matter a one if condition. It ll be better to look at the current code and see how cleanly it is done. As the OPP decoder table in the AM335x datasheet will tell you it's not that simple. I guess your previous comment was about the code complexity when a new variant of the board comes. Coming to OPP tables: Frankly, I don't know what happened during AM33xx times. I am just trying to make things simpler and cleaner. Do you mean here, we need to support all OPPs in U-Boot? Are you expecting complete OPP table to get from e-fuse values for AM43xx? As per my understanding from working on OMAP, U-Boot supports only OPP_NOM( or the safe OPP to boot). Please correct me if I am wrong. I hope the verbiage above helps you get an idea of why i am insisting on a change here. I am not asking U-Boot to have the complete OPP table. That's for the kernel + device-tree to handle. If there's no eFuse data in the devices, hard luck. We do the only thing we can for reliable boots and that's to use an OPP which is reliable all the time. If you still think OPP_NOM is the right choice please go ahead and use it. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Wed, Nov 27, 2013 at 4:34 AM, Lokesh Vutla lokeshvu...@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. 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. 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. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Sun, Nov 24, 2013 at 11:46 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Friday 22 November 2013 01:56 AM, Vaibhav Bedia wrote:
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
[...]
#define NON_SECURE_SRAM_START 0x402F0400
#define NON_SECURE_SRAM_END0x4034
#define SRAM_SCRATCH_SPACE_ADDR0x4033C000
+#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
+#define AM4372_BOARD_NAME_END SRAM_SCRATCH_SPACE_ADDR + 0xC
Why do you need to keep the struct address hardcoded like this?
FYI, this is not struct address. This is the place where where I am storing
board name.
This helps in detecting the board.
It ll be good to understand the code properly and comment.
My bad. Should have looked closer.
[...]
+static inline int board_is_eposevm(void)
+{
+ return !strncmp(am43xx_board_name, AM43EPOS, HDR_NAME_LEN);
+}
+
+static inline int board_is_gpevm(void)
+{
+ return !strncmp(am43xx_board_name, AM43__GP, HDR_NAME_LEN);
+}
+
Looks like you got the EEPROM content updated ;)
There is nothing updated. This is what I have used previously.
Please recollect your comments properly.
Well it would help if you added in a more detailed changelog for the different
variants of the patches highlighting what's changed and if some comment is
being ignored the reason for the same.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 06/14] ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
On Sun, Nov 24, 2013 at 11:48 PM, Lokesh Vutla lokeshvu...@ti.com wrote: On Friday 22 November 2013 01:58 AM, Vaibhav Bedia wrote: On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: [...] +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + struct am43xx_board_id header; + + if (read_eeprom(header) 0) + puts(Could not get board ID.\n); Hmm... didn't the previous patch read the EEPROM? This is as per suggested by Tom. If I populate a common structure it ll bread NOR boot. I hope you understand what happens in NOR boot. Care to explain how this particular snippet relates to NOR boot? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 07/14] ARM: AM43xx: Select clk source for Timer2
On Sun, Nov 24, 2013 at 11:53 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Friday 22 November 2013 02:01 AM, Vaibhav Bedia wrote:
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
Selecting the Master osc clk as Timer2 clock source.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/clock_am43xx.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index c4890f2..22963b7 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -18,6 +18,7 @@
struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
+struct cm_dpll *const cmdpll = (struct cm_dpll *)CM_DPLL;
const struct dpll_regs dpll_mpu_regs = {
.cm_clkmode_dpll= CM_WKUP + 0x560,
@@ -107,4 +108,7 @@ void enable_basic_clocks(void)
};
do_enable_clocks(clk_domains, clk_modules_explicit_en, 1);
+
+ /* Select the Master osc clk as Timer2 clock source */
+ writel(0x1, cmdpll-clktimer2clk);
I really don't see a point of copying whatever AM335x does. You should
have a good reason for not using the other timers :P
Again nothing is copied here, I am reusing the code what ever is present.
I don't have any restrictions to choose any timer here. All OMAPs and AM uses
timer 2
and I used it. I have already told you why I can't use timer1.
If by that you are referring to your reasoning that there's a base
address that's already
there and hence let's reuse it, then yes you did.
First please give me a *valid reason* why I should not use timer2, then Ill
think of using other timer.
As per my understanding there is nothing wrong to reuse what ever is present.
Please be specific when you are commenting.
And the reuse without rethink is exactly how over a period of time we
end up with choices in s/w that no one can recollect have it your way :)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/14] ARM: AM43xx: mux: Update mux data
On Sun, Nov 24, 2013 at 11:59 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Friday 22 November 2013 02:04 AM, Vaibhav Bedia wrote:
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the mux data for UART, adding data for i2c0 and mmc.
And also updating pad_signals structure.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 45
+
board/ti/am43xx/mux.c | 22 ++--
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 0206912..98fc2b5 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -137,6 +137,51 @@ struct pad_signals {
int mcasp0_fsr;
int mcasp0_axr1;
int mcasp0_ahclkx;
+ int xdma_event_intr0;
+ int xdma_event_intr1;
+ int nresetin_out;
+ int porz;
+ int nnmi;
+ int osc0_in;
+ int osc0_out;
+ int rsvd1;
+ int tms;
+ int tdi;
+ int tdo;
+ int tck;
+ int ntrst;
+ int emu0;
+ int emu1;
+ int osc1_in;
+ int osc1_out;
+ int pmic_power_en;
+ int rtc_porz;
+ int rsvd2;
+ int ext_wakeup;
+ int enz_kaldo_1p8v;
+ int usb0_dm;
+ int usb0_dp;
+ int usb0_ce;
+ int usb0_id;
+ int usb0_vbus;
+ int usb0_drvvbus;
+ int usb1_dm;
+ int usb1_dp;
+ int usb1_ce;
+ int usb1_id;
+ int usb1_vbus;
+ int usb1_drvvbus;
+ int ddr_resetn;
+ int ddr_csn0;
+ int ddr_cke;
+ int ddr_ck;
+ int ddr_nck;
+ int ddr_casn;
+ int ddr_rasn;
+ int ddr_wen;
+ int ddr_ba0;
+ int ddr_ba1;
+ int ddr_ba2;
};
IIRC not all the pads over here have any IO control. Some are analog pins
and some like JTAG, PORz really shouldn't be meddled with if the h/w does
expose some configuration. Please revisit this change.
Nothing to be revisited here. I have to use ddr_ba2 for VTT, so I have
populated the structure till this point.
I don't see any error to update a structure so that I can use the desired
pins.
I am not using the pins what ever you have mentioned. I purposefully
populated those
because I don't want make them as reserved.
I think i gave a good enough technical reason why that's not a good thing to do.
If you really don't see the shortcomings of that i have nothing more
to add here.
#endif /* _MUX_AM43XX_H_ */
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 700e9a7..46bad01 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -12,8 +12,24 @@
#include board.h
static struct module_pin_mux uart0_pin_mux[] = {
- {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
- {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {OFFSET(uart0_rxd), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
+ {OFFSET(uart0_txd), (MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL)},
+ {-1},
SLEWCTRL is typically not changed. You might want to double check this
portion
with the h/w folks.
I have checked with h/w folks, they said nothing wrong here.
Fine with me.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM
On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote: On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM. Following are the DPLL locking frequencies at OPP NOM: MPU locks at 600MHz Core locks at 1000MHz Per locks at 960MHz DDR locks at 266MHz As mentioned earlier, this hardcoded frequency approach is really not scalable when you have more device variants coming in. Just look at the AM335x changes on how this gets complicated. We already had a discussion on this during V1 of this series. Sekhar and Tom replied to you comments. What is the point in asking the same question again? Because i don't recall any conclusion being reached on that thread? Because the objective of a patch review is to come up with a solution which learns from the past and doesn't try to brush the past issues under the carpet under the assumption that the shiny new device will never have bugs? Since you are very concerned here. Why are you feeling it so complicated when new variants come? We can always differentiate the new variant from the old ones and can pass dpll structure accordingly. It is just a matter a one if condition. It ll be better to look at the current code and see how cleanly it is done. As the OPP decoder table in the AM335x datasheet will tell you it's not that simple. Frankly, i could care less about this change... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2
On Mon, Nov 25, 2013 at 12:13 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Friday 22 November 2013 02:16 AM, Vaibhav Bedia wrote: On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A) Adding LPDDR2 init sequence and register details for the same. Below is the brief description of LPDDR2 init sequence: - Configure VTP - Configure DDR IO settings - Disable initialization and refreshes until EMIF registers are programmed. - Program Timing registers - Program PHY control and Temp alert and ZQ config registers. - Enable initialization and refreshes and configure SDRAM CONFIG register - Wait till initialization is complete and the configure MR registers. This patch does too many things, some of which affects AM335x and needs to be split up. I lost track of what you were doing as i scrolled down :\ It does only two things. Update IO settings and emif configuration. I wanted to keep these things in a single patch so that if some functionality breaks down I can burn down to this patch. That doesn't mean that you mix up everything in one humungous patch and try to force your way through. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/cpu/armv7/am33xx/ddr.c| 147 +++- arch/arm/cpu/armv7/am33xx/emif4.c | 25 +++- arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |3 + arch/arm/include/asm/arch-am33xx/cpu.h |5 + arch/arm/include/asm/arch-am33xx/ddr_defs.h| 33 - arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |1 + arch/arm/include/asm/emif.h| 12 ++ board/isee/igep0033/board.c| 10 +- board/phytec/pcm051/board.c| 12 +- board/siemens/dxr2/board.c | 10 +- board/siemens/pxm2/board.c | 10 +- board/siemens/rut/board.c | 10 +- board/ti/am335x/board.c| 40 +- board/ti/am43xx/board.c| 66 + board/ti/ti814x/evm.c |4 +- board/ti/ti816x/evm.c | 12 +- 16 files changed, 373 insertions(+), 27 deletions(-) As the diffstat above shows, this patch affects a critical portion of AM335x, TI81xx and and at the same time adds in support for a new SoC. If that's not mixing up things i honestly don't know what is. And if you have some discussions off-list you should at least attempt to capture the summary of what was agreed to do taken up as TODO for the benefit of others. If there's a agreed upon patch to improving the code that helps is overlooking some short term compromises. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Mon, Nov 25, 2013 at 12:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Friday 22 November 2013 02:22 AM, Vaibhav Bedia wrote:
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
[...]
-/*
- * Get SDRAM type connected to EMIF.
- * Assuming similar SDRAM parts are connected to both EMIF's
- * which is typically the case. So it is sufficient to get
- * SDRAM type from EMIF1.
- */
-u32 emif_sdram_type()
-{
- struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
-
- return (readl(emif-emif_sdram_config)
- EMIF_REG_SDRAM_TYPE_MASK) EMIF_REG_SDRAM_TYPE_SHIFT;
-}
-
static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr)
{
u32 mr;
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index c98ab7f..646e50f 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -138,6 +138,14 @@
#define LPDDR2_DATA2_IOCTRL_VALUE 0x2294
#define LPDDR2_DATA3_IOCTRL_VALUE 0x2294
+#define DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_IOCTRL_VALUE 0x84
+#define DDR3_DATA0_IOCTRL_VALUE 0x84
+#define DDR3_DATA1_IOCTRL_VALUE 0x84
+#define DDR3_DATA2_IOCTRL_VALUE 0x84
+#define DDR3_DATA3_IOCTRL_VALUE 0x84
+
/**
* Configure DMM
*/
diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
index ce6b229..b4a8c9f 100644
--- a/arch/arm/include/asm/emif.h
+++ b/arch/arm/include/asm/emif.h
@@ -1151,6 +1151,20 @@ static inline u32 get_emif_rev(u32 base)
EMIF_REG_MAJOR_REVISION_SHIFT;
}
+/*
+ * Get SDRAM type connected to EMIF.
+ * Assuming similar SDRAM parts are connected to both EMIF's
+ * which is typically the case. So it is sufficient to get
+ * SDRAM type from EMIF1.
+ */
+static inline u32 emif_sdram_type(void)
+{
+ struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
+
+ return (readl(emif-emif_sdram_config)
+ EMIF_REG_SDRAM_TYPE_MASK) EMIF_REG_SDRAM_TYPE_SHIFT;
+}
+
This change don't make any sense to me. How are the EMIF register bits
any indication
of what memory time is used especially for DDR2/3?
What is not making sense here ?
If you go and read EMIF spec, it is clearly written that on coming out of
reset
HW sequence starts according to the value populated in SDRAM config register.
As far as I am concerned this is the best way to differentiate between
Memories.
Take a moment to think about where that register value comes from. Does it
somehow automagically get reconfigured when the chip is put in a board with
LPDDR2 vs DDR2 vs DDR3? While you are at it also look at the JEDEC specs
to figure out is there's some way to probe the DDR2/3 memory types.
Can you tell me a better way to differentiate between memories in emif file ?
Definitely I should not use board_is_foo() functions.
AFAIK there is none and hence this way of trying to get the memory type
is broken.
Moreover, my understanding was that one of the prime functions of the EEPROM
board data was to enable differentiation between the memory types.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 01/14] ARM: AM43xx: Update the base addresses of modules
Hi Lokesh, On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: [...] +#define CM_DPLL0x44DF4200 +#define CM_RTC 0x44df8500 nit: CM_RTC address should be in caps for the sake of consistency #define PRM_RSTCTRL(PRCM_BASE + 0x4000) #define PRM_RSTST (PRM_RSTCTRL + 4) diff --git a/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h b/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h index 4509a23..9080b6f 100644 --- a/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h +++ b/arch/arm/include/asm/arch-am33xx/hardware_ti814x.h @@ -27,6 +27,8 @@ #define PRCM_BASE 0x4818 #define CM_PER 0x44E0 #define CM_WKUP0x44E00400 +#define CM_DPLL0x44E00500 +#define CM_RTC 0x44E00800 Looking at these address i strongly suspect the CM_XXX ones are wrong for the TI81xx family. Does this really match with the TRM? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 07/14] ARM: AM43xx: Select clk source for Timer2
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
Selecting the Master osc clk as Timer2 clock source.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/clock_am43xx.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index c4890f2..22963b7 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -18,6 +18,7 @@
struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
+struct cm_dpll *const cmdpll = (struct cm_dpll *)CM_DPLL;
const struct dpll_regs dpll_mpu_regs = {
.cm_clkmode_dpll= CM_WKUP + 0x560,
@@ -107,4 +108,7 @@ void enable_basic_clocks(void)
};
do_enable_clocks(clk_domains, clk_modules_explicit_en, 1);
+
+ /* Select the Master osc clk as Timer2 clock source */
+ writel(0x1, cmdpll-clktimer2clk);
I really don't see a point of copying whatever AM335x does. You should
have a good reason for not using the other timers :P
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 06/14] ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote: [...] +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + struct am43xx_board_id header; + + if (read_eeprom(header) 0) + puts(Could not get board ID.\n); Hmm... didn't the previous patch read the EEPROM? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
Adding LPDDR2 init sequence and register details for the same.
Below is the brief description of LPDDR2 init sequence:
- Configure VTP
- Configure DDR IO settings
- Disable initialization and refreshes until EMIF registers are programmed.
- Program Timing registers
- Program PHY control and Temp alert and ZQ config registers.
- Enable initialization and refreshes and configure SDRAM CONFIG register
- Wait till initialization is complete and the configure MR registers.
This patch does too many things, some of which affects AM335x and needs to be
split up. I lost track of what you were doing as i scrolled down :\
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/ddr.c| 147
+++-
arch/arm/cpu/armv7/am33xx/emif4.c | 25 +++-
arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |3 +
arch/arm/include/asm/arch-am33xx/cpu.h |5 +
arch/arm/include/asm/arch-am33xx/ddr_defs.h| 33 -
arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |1 +
arch/arm/include/asm/emif.h| 12 ++
board/isee/igep0033/board.c| 10 +-
board/phytec/pcm051/board.c| 12 +-
board/siemens/dxr2/board.c | 10 +-
board/siemens/pxm2/board.c | 10 +-
board/siemens/rut/board.c | 10 +-
board/ti/am335x/board.c| 40 +-
board/ti/am43xx/board.c| 66 +
board/ti/ti814x/evm.c |4 +-
board/ti/ti816x/evm.c | 12 +-
16 files changed, 373 insertions(+), 27 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
index fa697c7..fbee51d 100644
--- a/arch/arm/cpu/armv7/am33xx/ddr.c
+++ b/arch/arm/cpu/armv7/am33xx/ddr.c
@@ -36,6 +36,74 @@ static struct ddr_data_regs *ddr_data_reg[2] = {
static struct ddr_cmdtctrl *ioctrl_reg = {
(struct ddr_cmdtctrl *)DDR_CONTROL_BASE_ADDR};
+static inline u32 get_mr(int nr, u32 cs, u32 mr_addr)
+{
+ u32 mr;
+
+ mr_addr |= cs EMIF_REG_CS_SHIFT;
+ writel(mr_addr, emif_reg[nr]-emif_lpddr2_mode_reg_cfg);
+
+ mr = readl(emif_reg[nr]-emif_lpddr2_mode_reg_data);
+ debug(get_mr: EMIF1 cs %d mr %08x val 0x%x\n, cs, mr_addr, mr);
+ if (((mr 0xff00) 8) == (mr 0xff)
+ ((mr 0x00ff) 16) == (mr 0xff)
+ ((mr 0xff00) 24) == (mr 0xff))
+ return mr 0xff;
+ else
+ return mr;
+}
+
+static inline void set_mr(int nr, u32 cs, u32 mr_addr, u32 mr_val)
+{
+ mr_addr |= cs EMIF_REG_CS_SHIFT;
+ writel(mr_addr, emif_reg[nr]-emif_lpddr2_mode_reg_cfg);
+ writel(mr_val, emif_reg[nr]-emif_lpddr2_mode_reg_data);
+}
+
+static void configure_mr(int nr, u32 cs)
+{
+ u32 mr_addr;
+
+ while (get_mr(nr, cs, LPDDR2_MR0) LPDDR2_MR0_DAI_MASK)
+ ;
+ set_mr(nr, cs, LPDDR2_MR10, 0x56);
+
+ set_mr(nr, cs, LPDDR2_MR1, 0x43);
+ set_mr(nr, cs, LPDDR2_MR2, 0x2);
+
+ mr_addr = LPDDR2_MR2 | EMIF_REG_REFRESH_EN_MASK;
+ set_mr(nr, cs, mr_addr, 0x2);
+}
+
+/*
+ * Configure EMIF4D5 registers and MR registers
+ */
+void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
+{
+ writel(0x0, emif_reg[nr]-emif_pwr_mgmt_ctrl);
+ writel(0x0, emif_reg[nr]-emif_pwr_mgmt_ctrl_shdw);
+ writel(0x1, emif_reg[nr]-emif_iodft_tlgc);
+ writel(regs-zq_config, emif_reg[nr]-emif_zq_config);
+
+ writel(regs-temp_alert_config,
emif_reg[nr]-emif_temp_alert_config);
+ writel(regs-emif_rd_wr_lvl_rmp_win,
+ emif_reg[nr]-emif_rd_wr_lvl_rmp_win);
+ writel(regs-emif_rd_wr_lvl_rmp_ctl,
+ emif_reg[nr]-emif_rd_wr_lvl_rmp_ctl);
+ writel(regs-emif_rd_wr_lvl_ctl, emif_reg[nr]-emif_rd_wr_lvl_ctl);
+ writel(regs-emif_rd_wr_exec_thresh,
+ emif_reg[nr]-emif_rd_wr_exec_thresh);
+
+ clrbits_le32(emif_reg[nr]-emif_sdram_ref_ctrl,
+EMIF_REG_INITREF_DIS_MASK);
+
+ writel(regs-sdram_config, emif_reg[nr]-emif_sdram_config);
+ writel(regs-ref_ctrl, emif_reg[nr]-emif_sdram_ref_ctrl);
+
+ configure_mr(nr, 0);
+ configure_mr(nr, 1);
+}
+
Why can't this portion be shared with the other OMAPs? It looks to be
following a recommended sequence and i can't see why that would vary.
It's just too hard to review so many changes in a single patch so i'll stop
here, sorry.
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH V2 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
[...]
#define NON_SECURE_SRAM_START 0x402F0400
#define NON_SECURE_SRAM_END0x4034
#define SRAM_SCRATCH_SPACE_ADDR0x4033C000
+#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
+#define AM4372_BOARD_NAME_END SRAM_SCRATCH_SPACE_ADDR + 0xC
Why do you need to keep the struct address hardcoded like this?
[...]
+static inline int board_is_eposevm(void)
+{
+ return !strncmp(am43xx_board_name, AM43EPOS, HDR_NAME_LEN);
+}
+
+static inline int board_is_gpevm(void)
+{
+ return !strncmp(am43xx_board_name, AM43__GP, HDR_NAME_LEN);
+}
+
Looks like you got the EEPROM content updated ;)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/14] ARM: AM43xx: mux: Update mux data
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the mux data for UART, adding data for i2c0 and mmc.
And also updating pad_signals structure.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 45
+
board/ti/am43xx/mux.c | 22 ++--
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 0206912..98fc2b5 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -137,6 +137,51 @@ struct pad_signals {
int mcasp0_fsr;
int mcasp0_axr1;
int mcasp0_ahclkx;
+ int xdma_event_intr0;
+ int xdma_event_intr1;
+ int nresetin_out;
+ int porz;
+ int nnmi;
+ int osc0_in;
+ int osc0_out;
+ int rsvd1;
+ int tms;
+ int tdi;
+ int tdo;
+ int tck;
+ int ntrst;
+ int emu0;
+ int emu1;
+ int osc1_in;
+ int osc1_out;
+ int pmic_power_en;
+ int rtc_porz;
+ int rsvd2;
+ int ext_wakeup;
+ int enz_kaldo_1p8v;
+ int usb0_dm;
+ int usb0_dp;
+ int usb0_ce;
+ int usb0_id;
+ int usb0_vbus;
+ int usb0_drvvbus;
+ int usb1_dm;
+ int usb1_dp;
+ int usb1_ce;
+ int usb1_id;
+ int usb1_vbus;
+ int usb1_drvvbus;
+ int ddr_resetn;
+ int ddr_csn0;
+ int ddr_cke;
+ int ddr_ck;
+ int ddr_nck;
+ int ddr_casn;
+ int ddr_rasn;
+ int ddr_wen;
+ int ddr_ba0;
+ int ddr_ba1;
+ int ddr_ba2;
};
IIRC not all the pads over here have any IO control. Some are analog pins
and some like JTAG, PORz really shouldn't be meddled with if the h/w does
expose some configuration. Please revisit this change.
#endif /* _MUX_AM43XX_H_ */
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 700e9a7..46bad01 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -12,8 +12,24 @@
#include board.h
static struct module_pin_mux uart0_pin_mux[] = {
- {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
- {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {OFFSET(uart0_rxd), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
+ {OFFSET(uart0_txd), (MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL)},
+ {-1},
SLEWCTRL is typically not changed. You might want to double check this portion
with the h/w folks.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
Following are the DPLL locking frequencies at OPP NOM:
MPU locks at 600MHz
Core locks at 1000MHz
Per locks at 960MHz
DDR locks at 266MHz
As mentioned earlier, this hardcoded frequency approach is really not
scalable when you have
more device variants coming in. Just look at the AM335x changes on how
this gets complicated.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/clock.c| 12 +++---
arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 15
arch/arm/cpu/armv7/am33xx/clock_am43xx.c |8 +--
arch/arm/include/asm/arch-am33xx/clock.h |7 +++---
board/ti/am43xx/board.c | 38
+++---
board/ti/am43xx/board.h |1 +
board/ti/am43xx/mux.c|5
7 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 8e5f3c6..0672798 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -101,9 +101,15 @@ void do_setup_dpll(const struct dpll_regs *dpll_regs,
static void setup_dplls(void)
{
const struct dpll_params *params;
- do_setup_dpll(dpll_core_regs, dpll_core);
- do_setup_dpll(dpll_mpu_regs, dpll_mpu);
- do_setup_dpll(dpll_per_regs, dpll_per);
+
+ params = get_dpll_core_params();
+ do_setup_dpll(dpll_core_regs, params);
+
+ params = get_dpll_mpu_params();
+ do_setup_dpll(dpll_mpu_regs, params);
+
+ params = get_dpll_per_params();
+ do_setup_dpll(dpll_per_regs, params);
writel(0x300, cmwkup-clkdcoldodpllper);
params = get_dpll_ddr_params();
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
index fabe259..92142c8 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
@@ -62,6 +62,21 @@ const struct dpll_params dpll_core = {
const struct dpll_params dpll_per = {
960, OSC-1, 5, -1, -1, -1, -1};
+const struct dpll_params *get_dpll_mpu_params(void)
+{
+ return dpll_mpu;
+}
+
+const struct dpll_params *get_dpll_core_params(void)
+{
+ return dpll_core;
+}
+
+const struct dpll_params *get_dpll_per_params(void)
+{
+ return dpll_per;
+}
+
void setup_clocks_for_console(void)
{
clrsetbits_le32(cmwkup-wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index 22963b7..97c00b4 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -48,15 +48,9 @@ const struct dpll_regs dpll_ddr_regs = {
.cm_idlest_dpll = CM_WKUP + 0x5A4,
.cm_clksel_dpll = CM_WKUP + 0x5AC,
.cm_div_m2_dpll = CM_WKUP + 0x5B0,
+ .cm_div_m4_dpll = CM_WKUP + 0x5B8,
};
-const struct dpll_params dpll_mpu = {
- -1, -1, -1, -1, -1, -1, -1};
-const struct dpll_params dpll_core = {
- -1, -1, -1, -1, -1, -1, -1};
-const struct dpll_params dpll_per = {
- -1, -1, -1, -1, -1, -1, -1};
-
void setup_clocks_for_console(void)
{
/* Do not add any spl_debug prints in this function */
diff --git a/arch/arm/include/asm/arch-am33xx/clock.h
b/arch/arm/include/asm/arch-am33xx/clock.h
index 519249e..7637457 100644
--- a/arch/arm/include/asm/arch-am33xx/clock.h
+++ b/arch/arm/include/asm/arch-am33xx/clock.h
@@ -98,13 +98,12 @@ extern const struct dpll_regs dpll_mpu_regs;
extern const struct dpll_regs dpll_core_regs;
extern const struct dpll_regs dpll_per_regs;
extern const struct dpll_regs dpll_ddr_regs;
-extern const struct dpll_params dpll_mpu;
-extern const struct dpll_params dpll_core;
-extern const struct dpll_params dpll_per;
-extern const struct dpll_params dpll_ddr;
extern struct cm_wkuppll *const cmwkup;
+const struct dpll_params *get_dpll_mpu_params(void);
+const struct dpll_params *get_dpll_core_params(void);
+const struct dpll_params *get_dpll_per_params(void);
const struct dpll_params *get_dpll_ddr_params(void);
void do_setup_dpll(const struct dpll_regs *, const struct dpll_params *);
void prcm_init(void);
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 723d0ca..2d1b8f9 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -65,12 +65,44 @@ static int read_eeprom(struct am43xx_board_id *header)
#ifdef CONFIG_SPL_BUILD
-const struct dpll_params dpll_ddr = {
- -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params epos_evm_dpll_ddr = {
+ 266, 24, 1, -1, 1, -1, -1};
+const struct dpll_params epos_evm_dpll_mpu = {
+
Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
[...]
-/*
- * Get SDRAM type connected to EMIF.
- * Assuming similar SDRAM parts are connected to both EMIF's
- * which is typically the case. So it is sufficient to get
- * SDRAM type from EMIF1.
- */
-u32 emif_sdram_type()
-{
- struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
-
- return (readl(emif-emif_sdram_config)
- EMIF_REG_SDRAM_TYPE_MASK) EMIF_REG_SDRAM_TYPE_SHIFT;
-}
-
static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr)
{
u32 mr;
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index c98ab7f..646e50f 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -138,6 +138,14 @@
#define LPDDR2_DATA2_IOCTRL_VALUE 0x2294
#define LPDDR2_DATA3_IOCTRL_VALUE 0x2294
+#define DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_IOCTRL_VALUE 0x84
+#define DDR3_DATA0_IOCTRL_VALUE 0x84
+#define DDR3_DATA1_IOCTRL_VALUE 0x84
+#define DDR3_DATA2_IOCTRL_VALUE 0x84
+#define DDR3_DATA3_IOCTRL_VALUE 0x84
+
/**
* Configure DMM
*/
diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
index ce6b229..b4a8c9f 100644
--- a/arch/arm/include/asm/emif.h
+++ b/arch/arm/include/asm/emif.h
@@ -1151,6 +1151,20 @@ static inline u32 get_emif_rev(u32 base)
EMIF_REG_MAJOR_REVISION_SHIFT;
}
+/*
+ * Get SDRAM type connected to EMIF.
+ * Assuming similar SDRAM parts are connected to both EMIF's
+ * which is typically the case. So it is sufficient to get
+ * SDRAM type from EMIF1.
+ */
+static inline u32 emif_sdram_type(void)
+{
+ struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
+
+ return (readl(emif-emif_sdram_config)
+ EMIF_REG_SDRAM_TYPE_MASK) EMIF_REG_SDRAM_TYPE_SHIFT;
+}
+
This change don't make any sense to me. How are the EMIF register bits
any indication
of what memory time is used especially for DDR2/3?
[...]
+static void enable_vtt_regulator(void)
+{
+ u32 temp;
+
+ /* enable module */
+ writel(0x0, AM33XX_GPIO0_BASE + OMAP_GPIO_CTRL);
+
+ /*enable output for GPIO0_22*/
+ writel((1 22), AM33XX_GPIO0_BASE + OMAP_GPIO_SETDATAOUT);
+ temp = readl(AM33XX_GPIO0_BASE + OMAP_GPIO_OE);
+ temp = temp ~(1 22);
+ writel(temp, AM33XX_GPIO0_BASE + OMAP_GPIO_OE);
+}
+
No magic nos. please. I think you have a #def the pin used for VTT regulator
in the config file - makes it simpler for others who design their own board.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
Hi, On Thu, Nov 7, 2013 at 4:16 PM, Tom Rini tr...@ti.com wrote: It's an open question on if TI81xx needs these set or was simply also setting them for historical reasons (and in turn was inherited by am335x). Based on Matt's test TI814x looks ok. I recall putting this code there for PG1.0 of TI8168 but i'm not sure if that version of silicon is out in the wild. If someone reports any issues with TI8168 it should be trivial to add this back in. For now this change looks fine to me. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Wed, Nov 13, 2013 at 3:48 AM, Lokesh Vutla lokeshvu...@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. You should at least check for the GP EVM (if possible) and then enable VTT. Doing this unconditionally is bound to cause problems later on. I would also put in a big comment over there so that folks who design their own board with DDR3 don't miss this fact. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
Hi Sekhar :) On Wed, Nov 13, 2013 at 11:08 AM, Sekhar Nori nsek...@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 lokeshvu...@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 ;) Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
Hi Tom,
On Wed, Nov 6, 2013 at 4:37 PM, Tom Rini tr...@ti.com wrote:
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.
With almost half a dozen of AM335x board variants floating around this
thing is bound to cause problems eventually. The EEPROM format
can simply be updated to fix this. If there's a big resistance in doing
this then we might as well live with it - but i would at least ask once ;)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] ARM: AM43xx: Select clk source for Timer2
Hi Lokesh, On Thu, Nov 7, 2013 at 8:43 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Vaibhav, On Wednesday 06 November 2013 06:10 PM, Vaibhav Bedia wrote: On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Selecting the Master osc clk as Timer2 clock source. I obviously missed the first round of patches for AM43xx here. Why is timer2 being used here? Don't we use the synctimer and timer1 in the kernel? In u-boot there is already code present to handle timer2 in arch/arm/cpu/armv7/omap-common/timer.c(Registers offsets are different for timer1 and timer2) . Trying to reuse the same here. This is how it is done in am335x also. Correct me if I am wrong. On AM335x that timer is used in U-Boot in the delay loop and later gets used in the kernel as a system timer. On AM437x it might be a good idea to use synctimer since it has some stabilization period requirements and that's going to affect the kernel boot eventually. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
Hi Tom,
On Thu, Nov 7, 2013 at 11:42 AM, Tom Rini tr...@ti.com wrote:
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[...]
diff --git a/board/ti/ti814x/evm.c b/board/ti/ti814x/evm.c
index e406326..0b76a77 100644
--- a/board/ti/ti814x/evm.c
+++ b/board/ti/ti814x/evm.c
@@ -33,15 +33,12 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
#ifdef CONFIG_SPL_BUILD
static const struct cmd_control evm_ddr2_cctrl_data = {
.cmd0csratio= 0x80,
- .cmd0dldiff = 0x04,
.cmd0iclkout= 0x00,
.cmd1csratio= 0x80,
- .cmd1dldiff = 0x04,
.cmd1iclkout= 0x00,
.cmd2csratio= 0x80,
- .cmd2dldiff = 0x04,
.cmd2iclkout= 0x00,
};
@@ -77,8 +74,6 @@ static const struct ddr_data evm_ddr2_data = {
.datagiratio0 = ((010) | (00)),
.datafwsratio0 = ((0x9010) | (0x900)),
.datawrsratio0 = ((0x5010) | (0x500)),
- .datauserank0delay = 1,
- .datadldiff0= 0x4,
};
void set_uart_mux_conf(void)
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
index 74d35e9..a53859e 100644
--- a/board/ti/ti816x/evm.c
+++ b/board/ti/ti816x/evm.c
@@ -59,21 +59,16 @@ static struct ddr_data ddr2_data = {
.datagiratio0 = ((0x010) | (0x00)),
.datafwsratio0 = ((0x13A10) | (0x13A0)),
.datawrsratio0 = ((0x8A10) | (0x8A0)),
- .datauserank0delay = 0x1,
- .datadldiff0= 0x0, /* depend on cpu rev, set later */
};
static struct cmd_control ddr2_ctrl = {
.cmd0csratio= 0x80,
- .cmd0dldiff = 0x04, /* reset value is 0x4 */
.cmd0iclkout= 0x00,
.cmd1csratio= 0x80,
- .cmd1dldiff = 0x04, /* reset value is 0x4 */
.cmd1iclkout= 0x00,
.cmd2csratio= 0x80,
- .cmd2dldiff = 0x04, /* reset value is 0x4 */
.cmd2iclkout= 0x00,
};
@@ -150,21 +145,16 @@ static struct ddr_data ddr3_data = {
.datagiratio0 = ((0x2010) | 0x200),
.datafwsratio0 = ((RD_DQS_GATE10) | (RD_DQS_GATE0)),
.datawrsratio0 = (((WR_DQS+0x40)10) | ((WR_DQS+0x40)0)),
- .datauserank0delay = 0x1,
- .datadldiff0= 0x0, /* depend on cpu rev, set later */
};
static const struct cmd_control ddr3_ctrl = {
.cmd0csratio= 0x100,
- .cmd0dldiff = 0x004, /* reset value is 0x4 */
.cmd0iclkout= 0x001,
.cmd1csratio= 0x100,
- .cmd1dldiff = 0x004, /* reset value is 0x4 */
.cmd1iclkout= 0x001,
.cmd2csratio= 0x100,
- .cmd2dldiff = 0x004, /* reset value is 0x4 */
.cmd2iclkout= 0x001,
};
@@ -198,11 +188,6 @@ void sdram_init(void)
config_dmm(evm_lisa_map_regs);
#ifdef CONFIG_TI816X_EVM_DDR2
- ddr2_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd0dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd1dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd2dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
if (CONFIG_TI816X_USE_EMIF0) {
ddr2_emif0_regs.emif_ddr_phy_ctlr_1 =
(get_cpu_rev() == 0x1 ? 0x010B : 0x030B);
@@ -217,8 +202,6 @@ void sdram_init(void)
#endif
#ifdef CONFIG_TI816X_EVM_DDR3
- ddr3_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
From a quick glance it looks like at least earlier variants of TI81xx
used these registers to work around some bugs? This might end up
breaking those. Note that TI81xx DDR frequencies are much higher
compared to AM335x so issues related to this might not show up
right now.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Thu, Nov 7, 2013 at 4:06 PM, Tom Rini tr...@ti.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/2013 03:56 PM, Vaibhav Bedia wrote:
Hi Tom,
On Wed, Nov 6, 2013 at 4:37 PM, Tom Rini tr...@ti.com wrote:
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.
With almost half a dozen of AM335x board variants floating around this
thing is bound to cause problems eventually. The EEPROM format
can simply be updated to fix this. If there's a big resistance in doing
this then we might as well live with it - but i would at least ask once ;)
The thing is, customers drop the EEPROM or come up with their own, see
the Siemens am335x boards :)
Customers fix a design and get rid of whatever they can ;)
I always considered the EEPROM as one of the ways of maintaining some
sanity amongst the numerous board variants that go around internally :P
I'll leave this for the right folks to decide then :)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] arm, am33xx: update for the am33xx based siemens boards
Hi Heiko, On Mon, Nov 4, 2013 at 10:30 PM, Heiko Schocher h...@denx.de wrote: Hello Vaibhav Bedia, Am 04.11.2013 20:45, schrieb Vaibhav Bedia: Hi Marek, On Mon, Nov 4, 2013 at 12:34 PM, Marek Vasutma...@denx.de wrote: Dear Vaibhav Bedia, On Mon, Nov 4, 2013 at 8:15 AM, Heiko Schocherh...@denx.de wrote: [...] Hups, missed this EMail ... :-( No problem. Happens all the time :) Hmm.. some boards from siemens do not use the RTC, so this approach is not possible here ... By unused do you mean it's not powered up or is it simply not programmed? Even if the RTC is not programmed the register would still be there. I don't have a board with me to check the behavior but i am guessing the RTC functionality doesn't need to be used to make use of the scratchpad registers. If your hardware's IP block's clock are not ungated, the register access to that IP block will usually not work. Yes, i understand that. However, in this case AFAICT the interface clock is always present and hence it should be possible to use the RTC registers. Moreover, i just noticed Tom applied a bootcount patch for AM335x [1] which does use the scratchpad register that i am pointing to. So unless there's some other board level difference that i am missing it should work. We see for example on the dxr2 board, that we cannot access the RTC registers ... also, they use it on other boards without RTC and all siemens boards should have the same manner. There is also a possibility to disable the RTC on am335x based boards, see: http://processors.wiki.ti.com/index.php/AM335x_Schematic_Checklist#RTC Yeah, if the RTC is completely disabled as documented above then the registers can't be accessed. In other cases i would expect the register access to still work. I just wanted to make sure that the usage of RTC for the bootcount has been considered. With the recent changes by Tom at least the other AM335x platforms use it so that's good. If it's about keeping the approaches consistent on the Siemens boards then i am fine with this. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/14] ARM: AM43xx: Update the base addresses of modules
HI Lokesh :)
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
PRCM, timer base addresses and offsets are different from
AM33xx. Updating the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/cpu.h | 17 +++--
arch/arm/include/asm/arch-am33xx/hardware.h|8
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |3 +++
arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |3 +++
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |3 +++
arch/arm/include/asm/arch-am33xx/hardware_ti816x.h |3 +++
6 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 52fa128..f463b27 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -237,6 +237,14 @@ struct cm_perpll {
unsigned int cpswclkstctrl; /* offset 0x144 */
unsigned int lcdcclkstctrl; /* offset 0x148 */
};
+
+/* Encapsulating Display pll registers */
+struct cm_dpll {
+ unsigned int resv1[2];
+ unsigned int clktimer2clk; /* offset 0x08 */
+ unsigned int resv2[10];
+ unsigned int clklcdcpixelclk; /* offset 0x34 */
+};
#else
/* Encapsulating core pll registers */
struct cm_wkuppll {
@@ -392,15 +400,12 @@ struct cm_perpll {
unsigned int resv40[7];
unsigned int cpgmac0clkctrl;/* offset 0xB20 */
};
-#endif /* CONFIG_AM43XX */
-/* Encapsulating Display pll registers */
struct cm_dpll {
- unsigned int resv1[2];
- unsigned int clktimer2clk; /* offset 0x08 */
- unsigned int resv2[10];
- unsigned int clklcdcpixelclk; /* offset 0x34 */
+ unsigned int resv1;
+ unsigned int clktimer2clk; /* offset 0x04 */
};
+#endif /* CONFIG_AM43XX */
/* Control Module RTC registers */
struct cm_rtc {
diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h
b/arch/arm/include/asm/arch-am33xx/hardware.h
index ee5fce0..b6db731 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware.h
@@ -38,7 +38,6 @@
#define DM_TIMER7_BASE 0x4804A000
/* GPIO Base address */
-#define GPIO0_BASE 0x48032000
Going by the patch description this looks an unrelated change.
Moreover, this base address looks wrong! GPIO0 is in wkup
domain for both AM335x and AM437x. I wonder how the
VTT control is working on AM335x. IIRC that was using a pin
from GPIO0.
#define GPIO1_BASE 0x4804C000
/* BCH Error Location Module */
@@ -48,13 +47,6 @@
#define EMIF4_0_CFG_BASE 0x4C00
#define EMIF4_1_CFG_BASE 0x4D00
-/* PLL related registers */
-#define CM_DPLL0x44E00500
-#define CM_DEVICE 0x44E00700
-#define CM_RTC 0x44E00800
-#define CM_CEFUSE 0x44E00A00
-#define PRM_DEVICE 0x44E00F00
-
/* DDR Base address */
#define DDR_CTRL_ADDR 0x44E10E04
#define DDR_CONTROL_BASE_ADDR 0x44E11404
diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
index e4231c8..ad9d7dd 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware_am33xx.h
@@ -17,6 +17,7 @@
#define UART0_BASE 0x44E09000
/* GPIO Base address */
+#define GPIO0_BASE 0x48032000
#define GPIO2_BASE 0x481AC000
/* Watchdog Timer */
@@ -30,6 +31,8 @@
#define PRCM_BASE 0x44E0
#define CM_PER 0x44E0
#define CM_WKUP0x44E00400
+#define CM_DPLL0x44E00500
+#define CM_RTC 0x44E00800
#define PRM_RSTCTRL(PRCM_BASE + 0x0F00)
#define PRM_RSTST (PRM_RSTCTRL + 8)
diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
index 3b665e6..4dbc789 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
@@ -17,6 +17,7 @@
#define UART0_BASE 0x44E09000
/* GPIO Base address */
+#define GPIO0_BASE 0x44E07000
Looks like this address is same for AM335x (what the code has
right now is incorrect) and AM437x. So you can move it back to
hardware.h if that's the general convention.
#define GPIO2_BASE 0x481AC000
/* Watchdog Timer */
@@ -30,6 +31,8 @@
#define PRCM_BASE 0x44DF
#defineCM_WKUP 0x44DF2800
#defineCM_PER
Re: [U-Boot] [PATCH 02/14] ARM: AM43xx: Adapt to ti_armv7_common.h config file
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Use ti_armv7_common.h config file to inclde the common configs. [...] +/* Clock Defines */ +#define V_OSCK 2400 /* Clock output from T2 */ +#define V_SCLK (V_OSCK) I know this is slightly unrelated but i don't think hardcoding the osc freq is a good idea. We should be reading the PRCM register to detect the sysboot settings and then use that similar to the kernel. Follow up patch? -/* Unsupported features */ -#undef CONFIG_USE_IRQ +/* NS16550 Configuration */ +#define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has UART0 */ I think the comment on base EVM is not applicable here ;) Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
From: Sekhar Nori nsek...@ti.com
Add support for reading onboard EEPROM to enable
board detection.
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/omap.h |2 ++
board/ti/am43xx/board.c | 46
+++
board/ti/am43xx/board.h | 32 +
include/configs/am43xx_evm.h|7 +
4 files changed, 87 insertions(+)
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index 2250721..10f05c9 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -27,5 +27,7 @@
#define NON_SECURE_SRAM_START 0x402F0400
#define NON_SECURE_SRAM_END0x4034
#define SRAM_SCRATCH_SPACE_ADDR0x4033C000
+#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
+#define AM4372_BOARD_NAME_END SRAM_SCRATCH_SPACE_ADDR + 0xC
#endif
#endif
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index dcd8cbb..4fc1a40 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -9,6 +9,8 @@
*/
#include common.h
+#include i2c.h
+#include asm/errno.h
#include spl.h
#include asm/arch/clock.h
#include asm/arch/sys_proto.h
@@ -17,6 +19,50 @@
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Read header information from EEPROM into global structure.
+ */
+static int read_eeprom(struct am43xx_board_id *header)
+{
+ /* Check if baseboard eeprom is available */
+ if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
+ printf(Could not probe the EEPROM at 0x%x\n,
+ CONFIG_SYS_I2C_EEPROM_ADDR);
+ return -ENODEV;
+ }
+
+ /* read the eeprom using i2c */
+ if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
+sizeof(struct am43xx_board_id))) {
+ printf(Could not read the EEPROM\n);
+ return -EIO;
+ }
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
+ /*
+* read the eeprom using i2c again,
+* but use only a 1 byte address
+*/
+ if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 1, (uchar
*)header,
+sizeof(struct am43xx_board_id))) {
+ printf(Could not read the EEPROM at 0x%x\n,
+ CONFIG_SYS_I2C_EEPROM_ADDR);
+ return -EIO;
+ }
+
+ if (header-magic != 0xEE3355AA) {
Same here.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] ARM: AM43xx: Select clk source for Timer2
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Selecting the Master osc clk as Timer2 clock source. I obviously missed the first round of patches for AM43xx here. Why is timer2 being used here? Don't we use the synctimer and timer1 in the kernel? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the mux data for UART, and adding data for i2c0 and mmc.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
board/ti/am43xx/mux.c | 24 ++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 0206912..e95efdd 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -16,7 +16,9 @@
__raw_writel(value, (CTRL_BASE + offset));
/* PAD Control Fields */
-#define SLEWCTRL (0x1 19)
+#define DSPULLUDEN (0x1 27) /* DS0 mode Pull-Up/Down enable */
+#define DSPULLUDDIS(0x0 27) /* DS0 mode Pull-Up/Down Disable */
+#define SLEWCTRL (0x1 19) /* Slow slew rate selection */
#define RXACTIVE (0x1 18)
#define PULLDOWN_EN(0x0 17) /* Pull Down Selection */
#define PULLUP_EN (0x1 17) /* Pull Up Selection */
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 700e9a7..818a046 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -12,8 +12,26 @@
#include board.h
static struct module_pin_mux uart0_pin_mux[] = {
- {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
- {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {OFFSET(uart0_rxd),
+(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
+ {OFFSET(uart0_txd),
+(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
+ {-1},
+};
+
+static struct module_pin_mux mmc0_pin_mux[] = {
+ {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {-1},
Hmm i don't think updating the DSPULL here is a good idea. Since not
all the pins
are used in U-Boot, this is just partially updating the pulls for the
low power state.
I would suggest leaving this bit for the kernel where things can be
updated without
updating the bootloader.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
Following are the DPLL locking frequencies at OPP NOM:
MPU locks at 600MHz
Core locks at 1000MHz
Per locks at 960MHz
DDR locks at 266MHz
Why is this not reading the eFuses to detect what speeds are actually supported
on a device? If the eFuses are not currently blown it's much much safer to start
off from the slowest OPP. Things might be working fine now but dialing to a high
frequency without detecting the supported rates is going to come back to haunt
us later.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/clock.c| 12 +++---
arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 15
arch/arm/cpu/armv7/am33xx/clock_am43xx.c |8 +--
arch/arm/include/asm/arch-am33xx/clock.h |7 +++---
board/ti/am43xx/board.c | 38
+++---
board/ti/am43xx/board.h |1 +
board/ti/am43xx/mux.c|5
7 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 8e5f3c6..0672798 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -101,9 +101,15 @@ void do_setup_dpll(const struct dpll_regs *dpll_regs,
static void setup_dplls(void)
{
const struct dpll_params *params;
- do_setup_dpll(dpll_core_regs, dpll_core);
- do_setup_dpll(dpll_mpu_regs, dpll_mpu);
- do_setup_dpll(dpll_per_regs, dpll_per);
+
+ params = get_dpll_core_params();
+ do_setup_dpll(dpll_core_regs, params);
+
+ params = get_dpll_mpu_params();
+ do_setup_dpll(dpll_mpu_regs, params);
+
+ params = get_dpll_per_params();
+ do_setup_dpll(dpll_per_regs, params);
writel(0x300, cmwkup-clkdcoldodpllper);
params = get_dpll_ddr_params();
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
index fabe259..92142c8 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
@@ -62,6 +62,21 @@ const struct dpll_params dpll_core = {
const struct dpll_params dpll_per = {
960, OSC-1, 5, -1, -1, -1, -1};
+const struct dpll_params *get_dpll_mpu_params(void)
+{
+ return dpll_mpu;
+}
+
+const struct dpll_params *get_dpll_core_params(void)
+{
+ return dpll_core;
+}
+
+const struct dpll_params *get_dpll_per_params(void)
+{
+ return dpll_per;
+}
+
void setup_clocks_for_console(void)
{
clrsetbits_le32(cmwkup-wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index 22963b7..97c00b4 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -48,15 +48,9 @@ const struct dpll_regs dpll_ddr_regs = {
.cm_idlest_dpll = CM_WKUP + 0x5A4,
.cm_clksel_dpll = CM_WKUP + 0x5AC,
.cm_div_m2_dpll = CM_WKUP + 0x5B0,
+ .cm_div_m4_dpll = CM_WKUP + 0x5B8,
};
-const struct dpll_params dpll_mpu = {
- -1, -1, -1, -1, -1, -1, -1};
-const struct dpll_params dpll_core = {
- -1, -1, -1, -1, -1, -1, -1};
-const struct dpll_params dpll_per = {
- -1, -1, -1, -1, -1, -1, -1};
-
void setup_clocks_for_console(void)
{
/* Do not add any spl_debug prints in this function */
diff --git a/arch/arm/include/asm/arch-am33xx/clock.h
b/arch/arm/include/asm/arch-am33xx/clock.h
index 519249e..7637457 100644
--- a/arch/arm/include/asm/arch-am33xx/clock.h
+++ b/arch/arm/include/asm/arch-am33xx/clock.h
@@ -98,13 +98,12 @@ extern const struct dpll_regs dpll_mpu_regs;
extern const struct dpll_regs dpll_core_regs;
extern const struct dpll_regs dpll_per_regs;
extern const struct dpll_regs dpll_ddr_regs;
-extern const struct dpll_params dpll_mpu;
-extern const struct dpll_params dpll_core;
-extern const struct dpll_params dpll_per;
-extern const struct dpll_params dpll_ddr;
extern struct cm_wkuppll *const cmwkup;
+const struct dpll_params *get_dpll_mpu_params(void);
+const struct dpll_params *get_dpll_core_params(void);
+const struct dpll_params *get_dpll_per_params(void);
const struct dpll_params *get_dpll_ddr_params(void);
void do_setup_dpll(const struct dpll_regs *, const struct dpll_params *);
void prcm_init(void);
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 723d0ca..e28e844 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -65,12 +65,44 @@ static int read_eeprom(struct am43xx_board_id *header)
#ifdef CONFIG_SPL_BUILD
-const struct dpll_params dpll_ddr = {
- -1, -1, -1, -1, -1, -1, -1};
+const
Re: [U-Boot] [PATCH 11/14] ARM: AM43xx: clocks: Add DPLL data for GP EVM
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Adding DPLLs Multiplier and DIvider values for GP EVM Following are the DPLL locking frequencies at OPP NOM MPU locks at 600MHz Core locks at 1000MHz Per locks at 960MHz DDR locks at 400MHz Comment on getting the data from eFuse or falling back to lower freq applies here too. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A) Adding LPDDR2 init sequence and register details for the same. Below is the brief description of LPDDR2 init sequence: - Configure VTP - Configure DDR IO settings - Disable initialization and refreshes until EMIF registers are programmed. - Program Timing registers - Program PHY control and Temp alert and ZQ config registers. - Enable initialization and refreshes and configure SDRAM CONFIG register - Wait till initialization is complete and the configure MR registers. Is there any public documentation to go with this? I would suggest sprinkling the code with comments to mention the different stages. BTW, no IO powerdown setting for now? [...] +ifeq ($(CONFIG_AM43XX),) +COBJS += ddr.o +COBJS += emif4.o +endif +COBJS-$(CONFIG_AM43XX) += emif4d5.o + Are the steps really different enough to warrant a new file? Can't the changes be handled properly in the code? How has this been handled in OMAPx where DDR3 and LPDDR both are supported? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C).
Adding details for the same.
Below is the brief description of DDR3 init sequence(SW leveling):
- Enable VTT regulator
- Configure VTP
- Configure DDR IO settings
- Disable initialization and refreshes until EMIF registers are programmed.
- Program Timing registers
- Program leveling registers
- Program PHY control and Temp alert and ZQ config registers.
Temp alert? Is that really relevant here?
- Enable initialization and refreshes and configure SDRAM CONFIG register
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/emif4d5.c |8 ++-
arch/arm/include/asm/arch-am33xx/ddr_defs.h | 10 ++-
board/ti/am43xx/board.c | 89
++-
3 files changed, 101 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/emif4d5.c
b/arch/arm/cpu/armv7/am33xx/emif4d5.c
index eea1fa3..8bac0f2 100644
--- a/arch/arm/cpu/armv7/am33xx/emif4d5.c
+++ b/arch/arm/cpu/armv7/am33xx/emif4d5.c
@@ -120,7 +120,7 @@ static void configure_mr(u32 base, u32 cs)
void do_sdram_init(const struct ctrl_ioregs *ioregs,
const struct emif_regs *regs,
- const u32 *ext_phy_ctrl_const_regs)
+ const u32 *ext_phy_ctrl_const_regs, u32 sdram_type)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
@@ -178,6 +178,8 @@ void do_sdram_init(const struct ctrl_ioregs *ioregs,
writel(regs-sdram_config, emif-emif_sdram_config);
writel(regs-ref_ctrl, emif-emif_sdram_ref_ctrl);
- configure_mr(EMIF1_BASE, 0);
- configure_mr(EMIF1_BASE, 1);
+ if (sdram_type == EMIF_SDRAM_TYPE_LPDDR2) {
+ configure_mr(EMIF1_BASE, 0);
+ configure_mr(EMIF1_BASE, 1);
+ }
}
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index 1880415..796e9df 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -134,6 +134,14 @@
#define LPDDR2_DATA2_IOCTRL_VALUE 0x2294
#define LPDDR2_DATA3_IOCTRL_VALUE 0x2294
+#define DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
+#define DDR3_ADDRCTRL_IOCTRL_VALUE 0x84
+#define DDR3_DATA0_IOCTRL_VALUE 0x84
+#define DDR3_DATA1_IOCTRL_VALUE 0x84
+#define DDR3_DATA2_IOCTRL_VALUE 0x84
+#define DDR3_DATA3_IOCTRL_VALUE 0x84
+
/**
* Configure DMM
*/
@@ -333,5 +341,5 @@ void config_ddr(unsigned int pll, unsigned int ioctrl,
void do_sdram_init(const struct ctrl_ioregs *ioregs,
const struct emif_regs *emif_regs,
- const u32 *ext_phy_ctrl_const_regs);
+ const u32 *ext_phy_ctrl_const_regs, u32 ddr_type);
#endif /* _DDR_DEFS_H */
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 83d184d..a943b45 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -140,6 +140,57 @@ const u32
ext_phy_ctrl_const_base_lpddr2[EMIF_EXT_PHY_CTRL_CONST_REG] = {
0x08102040
};
+const struct ctrl_ioregs ioregs_ddr3 = {
+ .cm0ioctl = DDR3_ADDRCTRL_IOCTRL_VALUE,
+ .cm1ioctl = DDR3_ADDRCTRL_WD0_IOCTRL_VALUE,
+ .cm2ioctl = DDR3_ADDRCTRL_WD1_IOCTRL_VALUE,
+ .dt0ioctl = DDR3_DATA0_IOCTRL_VALUE,
+ .dt1ioctl = DDR3_DATA0_IOCTRL_VALUE,
+ .dt2ioctrl = DDR3_DATA0_IOCTRL_VALUE,
+ .dt3ioctrl = DDR3_DATA0_IOCTRL_VALUE,
+ .emif_sdram_config_ext = 0x0043,
+};
+
+const struct emif_regs ddr3_emif_regs_400Mhz = {
+ .sdram_config = 0x638413B2,
+ .ref_ctrl = 0x0C30,
+ .sdram_tim1 = 0xEAAAD4DB,
+ .sdram_tim2 = 0x266B7FDA,
+ .sdram_tim3 = 0x107F8678,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x50074BE4,
+ .temp_alert_config = 0x0,
+ .emif_ddr_phy_ctlr_1= 0x0E084007,
+ .emif_ddr_ext_phy_ctrl_1= 0x08020080,
+ .emif_ddr_ext_phy_ctrl_2= 0x00400040,
+ .emif_ddr_ext_phy_ctrl_3= 0x00400040,
+ .emif_ddr_ext_phy_ctrl_4= 0x00400040,
+ .emif_ddr_ext_phy_ctrl_5= 0x00400040
+};
+
+const u32 ext_phy_ctrl_const_base_ddr3[EMIF_EXT_PHY_CTRL_CONST_REG] = {
+ 0x00400040,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x00340034,
+ 0x00340034,
+
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Wed, Nov 6, 2013 at 8:25 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Wednesday 06 November 2013 06:08 PM, Vaibhav Bedia wrote:
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
From: Sekhar Nori nsek...@ti.com
Add support for reading onboard EEPROM to enable
board detection.
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/omap.h |2 ++
board/ti/am43xx/board.c | 46
+++
board/ti/am43xx/board.h | 32 +
include/configs/am43xx_evm.h|7 +
4 files changed, 87 insertions(+)
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index 2250721..10f05c9 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -27,5 +27,7 @@
#define NON_SECURE_SRAM_START 0x402F0400
#define NON_SECURE_SRAM_END0x4034
#define SRAM_SCRATCH_SPACE_ADDR0x4033C000
+#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
+#define AM4372_BOARD_NAME_END SRAM_SCRATCH_SPACE_ADDR + 0xC
#endif
#endif
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index dcd8cbb..4fc1a40 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -9,6 +9,8 @@
*/
#include common.h
+#include i2c.h
+#include asm/errno.h
#include spl.h
#include asm/arch/clock.h
#include asm/arch/sys_proto.h
@@ -17,6 +19,50 @@
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Read header information from EEPROM into global structure.
+ */
+static int read_eeprom(struct am43xx_board_id *header)
+{
+ /* Check if baseboard eeprom is available */
+ if (i2c_probe(CONFIG_SYS_I2C_EEPROM_ADDR)) {
+ printf(Could not probe the EEPROM at 0x%x\n,
+ CONFIG_SYS_I2C_EEPROM_ADDR);
+ return -ENODEV;
+ }
+
+ /* read the eeprom using i2c */
+ if (i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0, 2, (uchar *)header,
+sizeof(struct am43xx_board_id))) {
+ printf(Could not read the EEPROM\n);
+ return -EIO;
+ }
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data
On Wed, Nov 6, 2013 at 8:32 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Wednesday 06 November 2013 06:13 PM, Vaibhav Bedia wrote:
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the mux data for UART, and adding data for i2c0 and mmc.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
board/ti/am43xx/mux.c | 24
++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 0206912..e95efdd 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -16,7 +16,9 @@
__raw_writel(value, (CTRL_BASE + offset));
/* PAD Control Fields */
-#define SLEWCTRL (0x1 19)
+#define DSPULLUDEN (0x1 27) /* DS0 mode Pull-Up/Down enable */
+#define DSPULLUDDIS(0x0 27) /* DS0 mode Pull-Up/Down Disable */
+#define SLEWCTRL (0x1 19) /* Slow slew rate selection */
#define RXACTIVE (0x1 18)
#define PULLDOWN_EN(0x0 17) /* Pull Down Selection */
#define PULLUP_EN (0x1 17) /* Pull Up Selection */
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 700e9a7..818a046 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -12,8 +12,26 @@
#include board.h
static struct module_pin_mux uart0_pin_mux[] = {
- {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
- {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {OFFSET(uart0_rxd),
+(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
+ {OFFSET(uart0_txd),
+(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
+ {-1},
+};
+
+static struct module_pin_mux mmc0_pin_mux[] = {
+ {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {-1},
Hmm i don't think updating the DSPULL here is a good idea. Since not
all the pins
are used in U-Boot, this is just partially updating the pulls for the
low power state.
I would suggest leaving this bit for the kernel where things can be
updated without
updating the bootloader.
These are the preferred settings given to me.
Any way if kernel is updating it overwrites these settings, it shouldn't
matter I guess..:)
It's better to clearly list down what configuration a particular
entity in the system is
responsible for. Doing partial updates her just makes issues harder to debug.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2
On Wed, Nov 6, 2013 at 8:45 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Wednesday 06 November 2013 06:27 PM, Vaibhav Bedia wrote: On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A) Adding LPDDR2 init sequence and register details for the same. Below is the brief description of LPDDR2 init sequence: - Configure VTP - Configure DDR IO settings - Disable initialization and refreshes until EMIF registers are programmed. - Program Timing registers - Program PHY control and Temp alert and ZQ config registers. - Enable initialization and refreshes and configure SDRAM CONFIG register - Wait till initialization is complete and the configure MR registers. Is there any public documentation to go with this? I would suggest sprinkling the code with comments to mention the different stages. Yep ll add the comments in the code.. BTW, no IO powerdown setting for now? You mean DDR IO settings? Yeah. I assume you have configured the dynamic power down bit properly. Can't tell without looking at the TRM. [...] +ifeq ($(CONFIG_AM43XX),) +COBJS += ddr.o +COBJS += emif4.o +endif +COBJS-$(CONFIG_AM43XX) += emif4d5.o + Are the steps really different enough to warrant a new file? Can't the changes be handled properly in the code? How has this been handled in OMAPx where DDR3 and LPDDR both are supported? Initially Tom also suggested not to use a new file. I tried with not to add a new file, but I ended up with many #ifdefs. EMIF is new IP(reused from OMAP5) very different from AM33xx EMIF IP. So to make things more cleaner I had to use a new file.. It really looks a step backward. The new IP should be an update to the old version and not just a complete overhaul of the programming model that folks are familiar with. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3
On Wed, Nov 6, 2013 at 8:54 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Wednesday 06 November 2013 06:32 PM, Vaibhav Bedia wrote: On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: GP EVM has 1GB DDR3 attached(Part no: MT47H128M16RT-187E:C). Adding details for the same. Below is the brief description of DDR3 init sequence(SW leveling): - Enable VTT regulator - Configure VTP - Configure DDR IO settings - Disable initialization and refreshes until EMIF registers are programmed. - Program Timing registers - Program leveling registers - Program PHY control and Temp alert and ZQ config registers. Temp alert? Is that really relevant here? Yes, Need to configure all the emif registers before accessing SDRAM. Ok. What's done on an AM437x system when the temp goes beyond a threshold? Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] arm, am33xx: update for the am33xx based siemens boards
Hi Heiko, On Mon, Nov 4, 2013 at 2:02 AM, Heiko Schocher h...@denx.de wrote: Patch 1 introduces bootcount support for the 3 siemens boards. As there is no other possibility on this boards, the bootcounter is stored in the environment. To prevent a saveenv on all reboots, a upgrade_available U-Boot Environment variable is introduced. I must be missing something here but as commented on v1 [1], could you clarify why the scratchpad register in RTC that should be persistent is not used? Regards, Vaibhav [1] http://www.mail-archive.com/u-boot@lists.denx.de/msg124429.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] arm, am33xx: update for the am33xx based siemens boards
On Mon, Nov 4, 2013 at 8:15 AM, Heiko Schocher h...@denx.de wrote: [...] Hups, missed this EMail ... :-( No problem. Happens all the time :) Hmm.. some boards from siemens do not use the RTC, so this approach is not possible here ... By unused do you mean it's not powered up or is it simply not programmed? Even if the RTC is not programmed the register would still be there. I don't have a board with me to check the behavior but i am guessing the RTC functionality doesn't need to be used to make use of the scratchpad registers. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] arm, am33xx: update for the am33xx based siemens boards
Hi Marek, On Mon, Nov 4, 2013 at 12:34 PM, Marek Vasut ma...@denx.de wrote: Dear Vaibhav Bedia, On Mon, Nov 4, 2013 at 8:15 AM, Heiko Schocher h...@denx.de wrote: [...] Hups, missed this EMail ... :-( No problem. Happens all the time :) Hmm.. some boards from siemens do not use the RTC, so this approach is not possible here ... By unused do you mean it's not powered up or is it simply not programmed? Even if the RTC is not programmed the register would still be there. I don't have a board with me to check the behavior but i am guessing the RTC functionality doesn't need to be used to make use of the scratchpad registers. If your hardware's IP block's clock are not ungated, the register access to that IP block will usually not work. Yes, i understand that. However, in this case AFAICT the interface clock is always present and hence it should be possible to use the RTC registers. Moreover, i just noticed Tom applied a bootcount patch for AM335x [1] which does use the scratchpad register that i am pointing to. So unless there's some other board level difference that i am missing it should work. Regards, Vaibhav [1] http://lists.denx.de/pipermail/u-boot/2013-August/161593.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] bootcount: store bootcount var in environment
Hi Heiko, On Tue, Oct 22, 2013 at 6:25 AM, Heiko Schocher h...@denx.de wrote: If no softreset save registers are found on the hardware bootcount is stored in the environment. To prevent a saveenv on all reboots, the environment variable upgrade_available is introduced. If upgrade_available is 0, bootcount is always 0 therefore no need to save the environment on u-boot boot, if upgrade_available is 1 bootcount is incremented in the environment and environment gets written on u-boot start. So the Userspace Applikation must set the upgrade_available and bootcount variable to 0 (for example with fw_setenv), if a boot was successfully. Signed-off-by: Heiko Schocher h...@denx.de Just curious... why not save the bootcount in a RTC scratchpad register? IIRC that's persistent across boot cycles if there's battery backup. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH] Makefile: allow boards to check file size limits
On Wed, Oct 20, 2010 at 10:46 AM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, October 20, 2010 00:38:08 Vaibhav Bedia wrote: please do not top post Sorry about the top posting. The size of other sections like the bss section also need to be accounted for when doing a size check. that really cannot be checked at compile time. it certainly cannot be done easily or with a few lines of shell code. Insufficient space for bss when doing something like a MMC read which requires large buffers causes system hangs for no apparent reason. that doesnt make much sense. bss is statically allocated. either it exists, or it doesnt. if bss doesnt work, your system/build is fundamentally screwed. Just displaying the binary size can be misleading IMHO. If the info printed contains the complete memory requirement (stack+heap+bss) then it can potentially save a lot of time during debugging either way, none of this is related to my patch. -mike -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH] Makefile: allow boards to check file size limits
Hi, The size of other sections like the bss section also need to be accounted for when doing a size check. Insufficient space for bss when doing something like a MMC read which requires large buffers causes system hangs for no apparent reason. Regards, Vaibhav On Wed, Oct 20, 2010 at 2:59 AM, Wolfgang Denk w...@denx.de wrote: Dear Mike Frysinger, In message 1287025103-26681-1-git-send-email-vap...@gentoo.org you wrote: Boards often have a reserved size limit on the flash where they're stored. Sometimes during upgrades or config changes, those limits are exceeded, but no one notices until they try to upgrade and the limit screws things up. Either not enough of U-Boot is written to flash (and so the reboot fails), or too much is written (and so things after it get clobbered). So allow boards to declare a size limit (in bytes) and have the build system check it while building. Signed-off-by: Mike Frysinger vap...@gentoo.org --- Makefile | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
On Tue, Sep 14, 2010 at 7:03 PM, V, Aneesh ane...@ti.com wrote: Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Vipin Kumar Sent: Tuesday, September 14, 2010 3:52 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On 9/14/2010 12:46 PM, Stefan Roese wrote: Hello Stefan, On Tuesday 14 September 2010 07:22:10 Vipin Kumar wrote: This is about a generic problem which may also be faced by other developers. Our SoC has a masked bootrom area which copies an image from NOR/NAND memories to an internal embedded SRAM. The size of this SRAM is only 8K. This binary initializes the DDR for larger binaries (u-boot/OS) to be placed in RAM and executed from there. I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Hi, On TI's OMAP based devices there is a minimal bootloader called as xloader based on U-Boot. It which takes care of initializing the RAM and loads the U-Boot binary built from the denx tree. The directory structure, ONENAND_spl does seem to based on xloader from the info by the author in the source code. Although it is possible to achieve significant size reduction by making minimal changes to the U-Boot code, problems come in when we have to selectively include some features and not make use of the whole framework due to the size limitation of the initial program loader. Since the directory structure, the build system and flow of xloader is similar to U-Boot.. how about leveraging this for making the spl generic? If linking against the various drivers directly instead of using the whole framework is fine then we could have a common source for both the initial loader and full fledged U-Boot. -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] ARMV7: Add support for TI OMAP4430 SDP
On Tue, Jun 15, 2010 at 10:09 AM, Steve Sakoman st...@sakoman.com wrote:
[...]
+int board_init(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
This should be moved outside the function. Relevant thread
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/31805
[...]
--
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] ARMV7: Add basic support for TI OMAP4
On Tue, Jun 15, 2010 at 10:09 AM, Steve Sakoman st...@sakoman.com wrote: + [...] +/* Declare the global data pointer - gd */ +DECLARE_GLOBAL_DATA_PTR; + Once the declaration in /board/ti/sdp4430/sdp.c is made global this won't be needed. [...] --- a/arch/arm/cpu/armv7/omap3/reset.S +++ b/arch/arm/cpu/armv7/omap4/lowlevel_init.S @@ -1,6 +1,11 @@ /* - * Copyright (c) 2009 Samsung Electronics. - * Minkyu Kang mk7.k...@samsung.com + * Board specific setup info + * + * (C) Copyright 2010 + * Texas Instruments, www.ti.com + * + * Author : + * Aneesh Vane...@ti.com * * See file CREDITS for list of people who contributed to this * project. @@ -12,7 +17,7 @@ * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the Extra space. Check other files also. [...] --- a/arch/arm/cpu/armv7/omap3/reset.S +++ b/arch/arm/cpu/armv7/omap4/sys_info.c @@ -1,9 +1,10 @@ /* - * Copyright (c) 2009 Samsung Electronics. - * Minkyu Kang mk7.k...@samsung.com + * (C) Copyright 2010 + * Texas Instruments, www.ti.com * - * See file CREDITS for list of people who contributed to this - * project. + * Author : + * Aneesh Vane...@ti.com + * Steve Sakoman st...@sakoman.com * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as @@ -12,7 +13,7 @@ * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the Extra / before PURPOSE [...] -- Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARMV7: Add support for TI OMAP4 Panda
[...]
+/**
+ * @brief board_init
+ *
+ * @return 0
+ */
+int board_init(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+
This should also be made global.
[...]
--
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 09/13] arm: add Cortex A9 support
On Fri, Apr 9, 2010 at 4:59 PM, Nishanth Menon menon.nisha...@gmail.comwrote:
On 04/08/2010 08:43 AM, Rabin Vincent wrote:
Add Cortex A9 support by copying the code for Cortex A8. The only
change is a removal of some OMAP3 specific code.
Thanks :), I was hoping to help in the near future by adding OMAP4 code
in cortex a9.. ;)
Acked-by: Michael Brandtmichael.bra...@stericsson.com
Signed-off-by: Rabin Vincentrabin.vinc...@stericsson.com
---
cpu/{arm_cortexa8 = arm_cortexa9}/Makefile |0
cpu/{arm_cortexa8 = arm_cortexa9}/config.mk |0
cpu/{arm_cortexa8 = arm_cortexa9}/cpu.c |0
cpu/{arm_cortexa8 = arm_cortexa9}/start.S| 26
+
cpu/{arm_cortexa8 = arm_cortexa9}/u-boot.lds |2 +-
5 files changed, 2 insertions(+), 26 deletions(-)
copy cpu/{arm_cortexa8 = arm_cortexa9}/Makefile (100%)
copy cpu/{arm_cortexa8 = arm_cortexa9}/config.mk (100%)
copy cpu/{arm_cortexa8 = arm_cortexa9}/cpu.c (100%)
copy cpu/{arm_cortexa8 = arm_cortexa9}/start.S (91%)
copy cpu/{arm_cortexa8 = arm_cortexa9}/u-boot.lds (97%)
looking at the % of reuse.. for a9, cant we avoid a copy? since a9 and
a8 are both v7 instruction set anyways,
how about cpu/arm_cortexa8,a9 etc replaced by cpu/armv7 and have cortex
and soc specific code within it?
Making the folders based on ISA version would be confusing as the other ARM
cores are not grouped that way.
As all Cortex processors implement the ARMv7 architecture a better grouping
IMHO would be cpu/cortex/a8 and cpu/cortex/a9. The common stuff can be under
cpu/cortex/.
option a:
cpu/armv7/
common code.[cS..]
/cortex_a8/
/cortex_a9/
soc specific code:
option 1:
cpu/armv7/cortex_a[89]/soc
or option 2:
cpu/armv7/soc
option b:
cpu/armv7_common/
cpu/cortex_a8/
cpu/cortex_a9/
(socs thier usual place cpu/cortex_a[89]/socx
option c:
cpu/armv7
cpu/armv7/soc1
cpu/armv7/soc2
etc..
v7 has both a8 and a9 codebases..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
