Hi Tom/Albert,
From: Rini, Tom
Sent: Friday, March 01, 2013 7:51 PM
To: Albert ARIBAUD
Cc: R, Sricharan; U-Boot; Stehle, Vincent
Subject: Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client
access - build warnings!
-BEGIN PGP SIGNED
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:
Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42
-0500)
are available in the git repository at:
On Thursday 21 February 2013 11:27 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:52 PM, R Sricharan wrote:
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit
9f024f62e4604274a23213dcee30016092e32e7b
/omap5_evm.h
@@ -55,6 +55,7 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
Reviewed-by: R Sricharan r.sricha...@ti.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -52,7 +52,7 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_OF_LIBFDT 1
-
+#define CONFIG_CMD_BOOTZ
Reviewed-by: R Sricharan r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot
/152834
Both the cleanup and ES2.0 support series against mainline is available
here
git://gitorious.org/u-boot-shared/u-boot.git omap5_es2
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] Changed the patch to use CONTROL_ID_CODE first
and then arm
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
[v2
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla
is not enabled because smart i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3
later.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] Addressed some of Nishanth's comments here.
Essentially added missing OPP_HIGH
Hi Nishanth,
On Tuesday 05 February 2013 01:46 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
--please be clear that these are for OPP_NOM. FYI, latest documentation
is 0.5 rev which
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm
Hi,
On Tuesday 05 February 2013 08:49 PM, Nishanth Menon wrote:
On 18:02-20130205, R Sricharan wrote:
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R
On Tuesday 05 February 2013 08:59 PM, Nishanth Menon wrote:
[..]
Answering all of your above questions here.
The above data is for OMAP4 and not OMAP5. This file was modified
here just to include dummy dividers. Because we were now using a
common dpll_params structure, there
From: Lokesh Vutla lokeshvu...@ti.com
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off
, OMAP4460 Panda boards
and verified MAKEALL for all armv7 boards.
Lokesh Vutla (4):
ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
ARM: OMAP4+: Cleanup emif specific files
ARM: OMAP4+: Make control module register structure generic
ARM: OMAP5: Clean up iosettings code
R Sricharan
From: Lokesh Vutla lokeshvu...@ti.com
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
From: Lokesh Vutla lokeshvu...@ti.com
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan r.sricha
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
[V2] Addressed Tom Rini's tr...@ti.com comments
arch/arm/cpu/armv7/omap-common/clocks
the omap4+ boards.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |5 +-
arch/arm/cpu/armv7/omap4/hw_data.c |3 +
arch/arm/cpu/armv7/omap4/hwinit.c | 36 -
arch/arm
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include
/152834
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R Sricharan (3):
ARM: OMAP5: Add silicon id support for ES2.0 revision.
ARM: OMAP5: clock: Add the prcm register changes required
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |5 +
arch/arm/cpu/armv7/omap5
is not enabled because smart i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/armv7/omap5/hwinit.c | 116
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 142
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent,
On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharan r.sricha...@ti.com
wrote:
Currently for ARM based cpu's, mmu pagetable attributes are set with
manager permissions for all 4GB address space. Because
Hi,
On Sunday 03 February 2013 07:49 PM, R Sricharan wrote:
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent,
On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharan r.sricha...@ti.com
wrote: i meant
Currently for ARM based cpu's, mmu pagetable attributes are set
On Sunday 03 February 2013 08:55 PM, Albert ARIBAUD wrote:
Hi R,
On Sun, 3 Feb 2013 19:52:04 +0530, R Sricharan r.sricha...@ti.com
wrote:
Hi,
On Sunday 03 February 2013 07:49 PM, R Sricharan wrote:
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent
Hi Tom,
On Thursday 31 January 2013 10:50 PM, Tom Rini wrote:
On Thu, Jan 31, 2013 at 11:32:30AM +0530, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP
On Thursday 31 January 2013 09:59 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/31/2013 12:51 AM, R Sricharan wrote:
From: Lokesh Vutla lokeshvu...@ti.com
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM
On Thursday 31 January 2013 10:10 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/31/2013 12:52 AM, R Sricharan wrote:
The current PRCM structure prototype directly matches the hardware
register layout. So there is a need to change this for every new
silicon revision
Hi Tom,
On Thursday 31 January 2013 10:31 PM, Tom Rini wrote:
On Thu, Jan 31, 2013 at 11:22:02AM +0530, R Sricharan wrote:
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan r.sricha...@ti.com
[snip
, OMAP4460 Panda boards
and verified MAKEALL for all armv7 boards.
Lokesh Vutla (4):
ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
ARM: OMAP4+: Cleanup emif specific files
ARM: OMAP4+: Make control module register structure generic
ARM: OMAP5: Clean up iosettings code
R Sricharan
From: Lokesh Vutla lokeshvu...@ti.com
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan r.sricha
From: Lokesh Vutla lokeshvu...@ti.com
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off
From: Lokesh Vutla lokeshvu...@ti.com
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
the omap4+ boards.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |5 +-
arch/arm/cpu/armv7/omap4/hw_data.c |4 +
arch/arm/cpu/armv7/omap4/hwinit.c | 36 -
arch/arm
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 79 +--
arch/arm/cpu/armv7/omap4/Makefile |1 -
arch/arm
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 140
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |4 +
arch/arm/cpu/armv7/omap5
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan
is not enabled because smart i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/armv7/omap5/hwinit.c | 116
/152563
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R Sricharan (3):
ARM: OMAP5: Add silicon id support for ES2.0 revision.
ARM: OMAP5: clock: Add the prcm register changes required
Hi,
On Saturday 01 December 2012 04:31 AM, Simon Glass wrote:
From: Arun Mankuzhi aru...@samsung.com
In Cortex-A15 architecture, when we run cache invalidate
the cache clean operation executes automatically.
So if there are any dirty cache lines before disabling the L2 cache
these will be
Hi Vincent,
On Monday 07 January 2013 08:14 PM, Vincent Stehlé wrote:
We introduce an OMAP5 specific version of arm_setup_identity_mapping(), which
makes the first page of the identity mapping invalid.
We want to unmap the region near address zero on HS OMAP devices, to avoid
speculative
Introduce a weak version of dram_bank_setup function
to allow a platform specific redefinition.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Vincent
of speculative prefetch aborts seen with CORTEX A15
otherwise.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Vincent Stehle v-ste...@ti.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35
Hi Stefan,
On Tuesday 08 January 2013 05:22 PM, Stefan Roese wrote:
On 01/08/2013 12:18 PM, R Sricharan wrote:
Introduce a weak version of dram_bank_setup function
to allow a platform specific redefinition.
This is used in the subsequent patch to setup dram region
without 'XN' attribute
Hi Vincent,
On Tuesday 08 January 2013 05:57 PM, Vincent Stehlé wrote:
On 01/08/2013 12:14 PM, R Sricharan wrote:
(..)
We had this problem of speculative aborts in the kernel uncompress code
as well, which maps all of 4GB address space. It was solved by setting
the non-DRAM region as non
/msg102709.html
R Sricharan (2):
ARM: mmu: Introduce weak dram_bank_setup function
ARM: mmu: Set domain permissions to client access
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35
arch/arm/include/asm
of speculative prefetch aborts seen on OMAP5
secure devices.
Signed-off-by: R Sricharan r.sricha...@ti.com
Tested-by: Vincent Stehle v-ste...@ti.com
Cc: Vincent Stehle v-ste...@ti.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap
Introduce a weak version of dram_bank_setup function
to allow a platform specific function.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Vincent Stehle v
Introduce a weak version of dram_bank_setup function
to allow a platform specific function.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Vincent Stehle v
On Tuesday 13 November 2012 11:42 PM, Robert P. J. Day wrote:
No functional changes, simply for readability.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
diff --git a/arch/arm/cpu/armv7/omap4/clocks.c
b/arch/arm/cpu/armv7/omap4/clocks.c
index 5bd0a88..12c5803 100644
---
On Wednesday 14 November 2012 02:19 PM, Lokesh Vutla wrote:
DMM_LISA_MAP registers program whether memory is mapped
on particular EMIF or not. Irrespective of these registers
EMIF is getting configured. Correcting the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Hi Kevin,
In the latest, pad mux and clocks for all
non-essential modules at U-BOOT were removed.
This might also cause the problem.
We can bring this back in u-boot by adding the following macros
and check if it works fine again.
include/configs/omap4_common.h
Hi,
Add support for adjusting the cachability of an L1 section by updating
the MMU. The mmu_set_region_dcache() function allows drivers to make
these changes after the MMU is set up.
It is implemented only for ARMv7 at present.
This is needed for LCD support, where we want to make the LCD
On Monday 08 October 2012 10:05 PM, Tom Rini wrote:
On Sat, Oct 6, 2012 at 4:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net
wrote:
Hi,
On Sat, 6 Oct 2012 13:02:49 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi All,
With Anatolij's fix in, ELDK4.2 still fails to build three
Hi Marek Vasut,
On Sun, Sep 30, 2012 at 6:48 PM, Marek Vasut ma...@denx.de wrote:
Dear R, Sricharan,
Hi Marek Vasut,
One of the keys to the success of U-Boot has been the number of
platforms that are supported. But part of supporting platforms is
needing people to volunteer
Hi Marek Vasut,
One of the keys to the success of U-Boot has been the number of
platforms that are supported. But part of supporting platforms is
needing people to volunteer to maintain them long term and help with
testing changes and so forth. So first of all, I've just tagged
@@
/*
* High Level Configuration Options
*/
-#define CONFIG_PANDA /* working with Panda */
Thanks..
I think similar unused macros are lying in
CONFIG_4430SDP, CONFIG_OMAP5430, CONFIG_5430EVM,
CONFIG_OMAP3_BEAGLE, etc.. Those needs cleanup as well..
Acked-by: R Sricharan r.sricha...@ti.com
Hi Tom,
[snip]
(I had attempted to bcc this to all listed maintainer, but that upset
Google greatly. I'll send this out manually instead later).
I'd like to put this out here for custodians and maintainers to
consider, especially in light of the device model work that's not just
coming but
Hi,
-- a/arch/arm/include/asm/arch-omap4/cpu.h
+++ b/arch/arm/include/asm/arch-omap4/cpu.h
@@ -138,6 +138,7 @@ struct watchdog {
#define I2C_BASE1 (OMAP44XX_L4_PER_BASE + 0x7)
#define I2C_BASE2 (OMAP44XX_L4_PER_BASE + 0x72000)
#define I2C_BASE3
by GENERATED_GBL_DATA_SIZE, though it is small.
SRAM size available for SPL code is a concern in OMAP4 platforms.
Do you prefer keeping CONFIG_SPL_STACK to NON_SECURE_SRAM_END ?.
Except for that
Acked-by: R Sricharan r.sricha...@ti.com
Thanks,
Sricharan
Hi,
On Tue, Aug 7, 2012 at 2:59 PM, Jassi Brar jaswinder.si...@linaro.org wrote:
The commit
f3f98bb0 : ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls
removed the config option aimed towards moving that stuff into kernel, which
renders some code unreachable. Remove that
Hi Tom,
[snip..]
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 7f05cb5..c697e0b 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -39,11 +39,6 @@
#define OMAP54XX_L4_WKUP_BASE
Hi Tom,
On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini tr...@ti.com wrote:
On 07/31/2012 01:33 AM, R, Sricharan wrote:
Hi Tom,
[snip..]
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 7f05cb5..c697e0b 100644
--- a/arch/arm/include/asm/arch
Correct.
DRAM_ADDR_SPACE_END should be 0x for OMAP5.
Thanks,
Sricharan
On Tue, Jul 31, 2012 at 9:12 PM, Tom Rini tr...@ti.com wrote:
On 07/31/2012 08:27 AM, R, Sricharan wrote:
Hi Tom,
On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini tr...@ti.com wrote:
On 07/31/2012 01:33 AM, R
file for PANDA was missed out. Adding it here
to ensure TFTP works fine on OMAP4 panda boards.
Tested this on OMAP4430 ES2.2, OMAP4460 ES1.1 PANDA boards.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
board/ti/panda/panda_mux_data.h | 44 +++
1 file
Aneesh,
[snip..]
If we are built with D-CACHE enabled but have run 'dcache off' and
then
attempt to flush unaligned regions we spam the console with
problems
that aren't true (as the cache was off).
Today we do cache maintenance operations after the dcache is
turned off.
One
Hi Roger,
If board config does not select CONFIG_USB_EHCI_OMAP (e.g.
omap4_sdp4430_config)
then the USB DPLL is stuck in running state and it prevents the system from
entering OFF mode (i.e. l3init domain is kept ON).
With this patch we unconditionally configure the USB DPLL so it
Hi Roger,
If board config does not select CONFIG_USB_EHCI_OMAP (e.g.
omap4_sdp4430_config)
then the USB DPLL is stuck in running state and it prevents the system from
entering OFF mode (i.e. l3init domain is kept ON).
With this patch we unconditionally configure the USB DPLL so it
Hi Aneesh,
On Thu, Jun 21, 2012 at 2:55 PM, Sricharan R r.sricha...@ti.com wrote:
Hi,
[snip..]
On 06/15/2012 07:48 AM, R, Sricharan wrote:
Hi,
On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.com wrote:
If we are built with D-CACHE enabled but have run 'dcache off
#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
While, this looks like to be the safest option till
we fix both the cache issue and alignment issue in USB stack.
Acked-by: R Sricharan r.sricha...@ti.com
Thanks,
Sricharan
___
U-Boot mailing list
U-Boot
Hi Tom,
On Fri, Jun 15, 2012 at 8:50 PM, Tom Rini tr...@ti.com wrote:
On 06/15/2012 08:18 AM, R, Sricharan wrote:
Hi,
[snip..]
If it is a problem with unaligned regions, then that is the only
thing to be fixed
right ?. Just trying to understand why this change is required
Hi,
On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote:
If we are built with D-CACHE enabled but have run 'dcache off' and then
attempt to flush unaligned regions we spam the console with problems
that aren't true (as the cache was off).
Today we do cache maintenance operations
Hi,
[snip..]
If it is a problem with unaligned regions, then that is the only
thing to be fixed
right ?. Just trying to understand why this change is required ?
The problem is that within the USB/network/filesystem stacks we have a
lot of not cache safe alignments apparently. Without
Hi Tom,
On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote:
If we are built with D-CACHE enabled but have run 'dcache off' and then
attempt to flush unaligned regions we spam the console with problems
that aren't true (as the cache was off).
Today we do cache maintenance
.
There are a lot of warnings during boot because some dplls are no
more locked by default. This could also break other drivers which
were dependent upon the bootloaders for their configurations.
R Sricharan (4):
ARM: OMAP4/5: Move gpmc clocks to essential group.
ARM: OMAP4/5: Move USB clocks
drivers. But this
is the only way to get things fixed in the kernel.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
include/configs/omap4_common.h |5 -
include/configs/omap5_evm.h|2 --
2 files changed, 7 deletions(-)
diff --git a/include/configs/omap4_common.h b/include
GPMC clocks are currently getting enabled as a part
non-essential clocks. This will be required during
NOR boot. Move this to essential group to keep the
functionality, when non-essential clocks are not
enabled.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap4/clocks.c
USB clocks will be required for fastboot, tftp
related functionalities. Move these clocks to
essential group inorder to have the functionality
working when non-essential clocks are not enabled.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap4/clocks.c | 10
USB module pads are getting enabled under non-essential
group. These will be required for fastboot, tftp support.
So move this to essential list to have them working when
non-essential pads are no more muxed.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
There are few checkpatch warnings
Hi Marek Vasut,
Ping..
+1
Thanks..
Thanks,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
arch/arm/cpu/armv7/omap-common/emif-common.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index db509c9..176520c 100644
---
Code currently tests for = 0xff. Micron manufacturer code is 0xff, so
Micron memory will not be detected!
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 32 +-
arch/arm/cpu/armv7/omap4/sdram_elpida.c |3 --
arch/arm/cpu/armv7/omap5/sdram.c | 31 +
arch/arm/include/asm/emif.h
Hi Steve,
[snip]
---
arch/arm/cpu/armv7/omap4/sdram_elpida.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index b538960..0599aaa 100644
---
Hi Albert,
Are you planning to take up the below patch ?
Thanks,
Sricharan
On Thu, May 17, 2012 at 3:22 PM, R Sricharan r.sricha...@ti.com wrote:
The following is the cleanup sequence in arch/arm/cpu/armv7/cpu.c
int cleanup_before_linux(void)
{
...
...
dcache_disable
R Sricharan (4):
ARM: OMAP4+: dmm: Take care of overlapping dmm and trap sections.
ARM: OMAP5: dmm: Create a tiler trap section.
ARM: OMAP5: Align memory used for testing to the power of 2
ARM: OMAP5: Correct the DRAM_ADDR_SPACE_END macro.
arch/arm/cpu/armv7/omap-common/emif
Hi Tom,
ah, this is what is there on OMAP5.
3 for DDR3
4 for LPDDR2-S4,
5 for LPDDR2-S2
4/5 are listed as reserved here :( http://www.ti.com/lit/pdf/spruh73
Atleast DDR3 encoding is same. So we can differentiate bw DDR3 and 2
in same way.
Is the reset value set correctly on
To meet certain timing requirements on the lpddr2 cmd and data phy
interfaces ,lpddr iopads have to be configured as differential buffers
and a Vref has to be internally generated and provided to these buffers.
Correcting the above settings here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Hi Tom,
ah, this is what is there on OMAP5.
3 for DDR3
4 for LPDDR2-S4,
5 for LPDDR2-S2
4/5 are listed as reserved here :( http://www.ti.com/lit/pdf/spruh73
Atleast DDR3 encoding is same. So we can differentiate bw DDR3 and 2
in same way.
Is the reset value set correctly on
Hi Lokesh,
@@ -56,7 +56,7 @@
#define CONTROL_ID_CODE (CTRL_BASE + 0x204)
/* To be verified */
-#define OMAP5_CONTROL_ID_CODE_ES1_0 0x0B85202F
+#define OMAP5_CONTROL_ID_CODE_ES1_0 0x0B94202F
ok, then the above comment /* To be verified */
can be removed as well
Hi Lokesh,
Adding precalculated timings for ddr3 with 1cs
adding required registers for ddr3
You want to mention the part name as well ?
nit in subject : and defining the additional registers required
for DDR3.
[snip..]
/* Dummy registers for OMAP44xx */
const
Hi Lokesh,
No need to Unlock DPLL initially.
DDR3 can work at normal OPP from initialozation
Why is it so ?
The commit log should make it clear why is it
nessecary to do the initialisations at higher frequency and
that becomes the reason for this patch.
Thanks,
Sricharan
Hi Tom,
In OMAP5432 EMIF controlller supports DDR3 device.
This patch adds support for ddr3 device intialization and configuration.
Initialization sequence is done as specified in JEDEC specs.
This also adds support for ddr3 leveling.
[snip]
@@ -975,8 +1070,12 @@ static void
1 - 100 of 191 matches
Mail list logo
